Gitlab's permission model is very inelastic, needs more granular configuration
(We're an EE customer on 10.3.6-ee 45d0f746 and in coordination with @teemo are filing some more general issues we've encountered with Gitlab in addition to our more specific issues. These are not specific "this thing is broken" issues, but more general architecture issues with potentially open-ended solutions).
The permissions noted https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions aren't very granular, and lump things we don't really care if anyone edits (e.g. project descriptions) with things that need more careful control (e.g. adding rw deploy keys).
Ideally Gitlab's permission model would be the following:
- You wouldn't have Guest/Reporter/Developer etc. hardcoded, but that would just be a default label with N number of permissions assigned to it
- You could create new user types (e.g.
ProjectConfigurator) and assign any number of actions from the vertical part of that table (or even none) to it, e.g. only
- These permissions could of course be (like existing permissions) synced to external LDAP groups
- Many of these permissions really could use splitting up into sub-permissions. E.g. there should be some permission for "trivial project config", we don't care if any contributor can edit the project description, add an icon for the project, or even add (but not change/remove) tags, but they shouldn't be able to setup pushing to remote repos and other more sensitive settings.
- Any user would still see stuff they can't edit (e.g. delete project), and could click that button, but instead of it being actioned the action would just have to be approved by a user with higher permissions through some dashboard
This would allow users to e.g. setup rw deploy keys, and add them to the project, where they'd be held until someone with
DudeWhoCanAddDeployKeys permission would approve them. This would reduce friction in managing permissions, i.e. the user adding the deploy key wouldn't have to do all the legwork, just approve the key.