Custom roles cannot be editable once used
We have an existing validation on memberships that ensure users are granted roles with an access level that "greater than or equal to" roles higher in the hierarchy only. Because access is inherited via nested namespaces, it would be misleading to allow users to set more restrictive roles for namespaces within other namespaces that they already have higher permissions for (because the higher permissions cascade down).
For example, I cannot be an Admin for a Group but a Guest for a sub-group within that Group. I can be a Guest for a Group and an Admin for a sub-group within that Group. The validation that ensures this is here: https://gitlab.com/gitlab-org/gitlab/-/blob/25e9b7bc2bc19acf779a587504e6762f5fc35414/app/models/member.rb#L586-592
When it comes to custom roles, we will want to perform a similar validation but it is more complex. For example, how do you compare 2 Custom Roles with the same base_access_level
?
Here is a scenario:
CustomGuestRole1:
* base_access_level: GUEST
* download_code: true
* view error tracking list: false
CustomGuestRole2:
* base_access_level: GUEST
* download_code: false
* view error tracking list: true
User1:
* ParentGroup1 -> CustomGuestRole1
* SubGroup1 -> CustomGuestRole2
This is allowed because the base_access_level
of both roles is the same. Can the user download_code
on SubGroup1
? According to the logic we have today, the answer would be Yes.
But later on, the admin goes in and edits the custom roles:
CustomGuestRole1:
* base_access_level: ADMIN
* download_code: true
* view error tracking list: false
CustomGuestRole2:
* base_access_level: GUEST
* download_code: true
* view error tracking list: true
Now, a user has a role that enables more for ParentGroup1
than for the SubGroup1
. This would be misleading for customers because they might think they are preventing User1
from viewing the error tracking list for SubGroup1
but the user would in fact be able to view error tracking for any groups within ParentGroup1
.
To prevent this scenario, we should not allow users to edit custom roles once they have been assigned to users. That way, we can validate that permissions are granted so that more restrictive roles are required higher up in the hierarchy.