RHCLOUD-36017 Custom roles cannot be created or updated using existin…

[EvanCasey13]

…g display_name for any system roles

Link(s) to Jira

https://issues.redhat.com/browse/RHCLOUD-36017

Description of Intent of Change(s)

When trying to create or update a role through the API you cannot use the same 'display_name' or 'name' as any system role or custom role that exists for the tenant already.

Local Testing

How can the feature be exercised?
How can the bug be exploited and fix confirmed?
Is any special local setup required?

Checklist

• if API spec changes are required, is the spec updated?
• are there any pre/post merge actions required? if so, document here.
• are theses changes covered by unit tests?
• if warranted, are documentation changes accounted for?
• does this require migration changes?
  • if yes, are they backwards compatible?
• is there known, direct impact to dependent teams/components?
  • if yes, how will this be handled?

Secure Coding Practices Checklist Link

• https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Practices Checklist

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

[EvanCasey13]

/retest

[EvanCasey13]

/retest

[Ellen-Yi-Dong]

/retest

[alechenninger]

I wonder if we should prefix all custom roles names automatically? Or try to differentiate them some different way? (an icon in the gui? or some "role type" column that designates a role as system or custom?)

Checking for system role names when a custom role is created doesn't necessarily prevent collisions from happening – for example a customer could name a role "Workspace Auditor" and then we later create a system role with the same name. Maybe that's fine and we're okay with that?

But at least for V2 Roles and GUI, I wonder if we should think about this differently? Curious what you think @coderbydesign ?

[petracihalova]

I suggest we take a step back and discuss what is expected here ... our goal is to prevent the creation of a new role with the same name as an existing custom role within the same tenant or system role ... however it should be still possible to create custom role with same name if this role belongs to different tenant .. we also need to consider the role’s name and display_name fields and how these may affect our approach ensuring we are handling both fields correctly