Permission Label Management
Problem to solve
One of the reasons Label management is difficult is that there is very little control over who can create or edit Labels at any level. Currently, Label creation and management of any sort seems to be allowed for any role above Guest, which allows any user to create confusing or redundant Labels, delete or rename Labels (potentially breaking reports), and litter Groups with what should be Project-level labels.
Intended users
The primary user would be any of the IT roles that might be a GitLab administrator, but all of our user personas would be affected by the outcome.
User experience goal
In an ideal world, a GitLab admin would be able to toggle the ability of users or roles to perform each of the following actions:
For Groups of which the user is a member:
- Create a Group-level Label
- Edit a Group-level Label
- Delete a Group-level Label
For Projects of which the user is a member:
- Create a Project-level Label
- Edit a Project-level Label
- Delete a Project-level Label
Proposal
Further details
Permissions and Security
This seems liek it might require a substantial rework to our existing permissions structure (particularly allowing user-level configuration), but perhaps an MVC (e.g., elevating Group-level Label Management to
Documentation
Affected pages would include:
- https://docs.gitlab.com/ee/user/permissions.html
- https://docs.gitlab.com/ee/user/project/labels.html
Availability & Testing
What does success look like, and how can we measure that?
The ability to demonstrate to customers that we have at least minimal protection over the integrity of their labels and all of the analytics they perform upon them.
What is the type of buyer?
I think this could be of benefit to anyone, at any tier, but Erin would probably be the most concerned of the buyer personas.
Is this a cross-stage feature?
This seems fairly focused on Plan (@gweaver )