Allow Labels to be Protected
Release notes
Problem to solve
Currently, labels can be created, deleted, or applied to resources by any authorized user (Reporter+
). For some issues, such as priority, it would be useful to restrict applying a label to particular users. Perhaps following a model similar to CODEOWNERS, whereby there is a file in .gitlab/ that allows particular labels to only be applied by specified users.
Intended users
User experience goal
Provide a good user experience for label visibility for unauthorized users while preventing that label from being applied or removed from the resource the user is currently viewing.
Proposal
- When creating a label, allow for that label to be marked as
Protected
- If
Protected
, specify which roles (and maybe specific users?) can edit/delete the label and add/remove the label to various resources. - Allow the ability to specify whether roles in descendant (and maybe children?) can apply or remove that label from the resource to which it is applied.
- If a role is unauthorized to apply a label, it does not show up in the label picker.
- If a role is unauthorized to remove a label, do not show the
x
on the label. - Within Boards when a list is configured to use a protected label, prevent unauthorized users from dragging and dropping the issue (or epic) card into that list.
- Show a
🔒 icon or something similar within the label to signify it is locked. - Extend this to the APIs such that when an unauthorized user tries to apply a protected label programmatically, the server responds with
HTTP 401 Unauthorized
.
Further details
Permissions and Security
Maintainer+
Documentation
- We will need to update the documentation.
Availability & Testing
- Unit test changes
- Integration test changes
- End-to-end test changes
What does success look like, and how can we measure that?
- Count of protected labels created over time
- Count of Groups/Projects using protected labels
- Count of protected labels being applied over time
What is the type of buyer?
- GitLab Ultimate as this mostly relates to use cases needed for an enterprise environment where compliance and or reporting standardization is required.
Is this a cross-stage feature?
It will likely involve some level of collaboration or FYI across:
- groupsource code
- groupcode review
- groupproject management
- groupproduct planning
- ~"group:certify"
- groupoptimize
- ~"group::access"
- ~"group::integrations"
Links / references
Edited by Gabe Weaver