Group Labels should not be visible for users without Group Role assigned

Release notes

Problem to solve

Users that receive access at a subgroup or project level are able to see labels that were created at the parent level (where the user doesn't have access). This is counter-to GitLab's typical cascading permission model, except in a few locations (albeit 3 of the 5 exist in settings):

  1. Group-defined Epics (that are not confidential) at the parent group are able to be used by projects in subgroups and seen at the top level, even when the user does not have a role defined at the parent group. (Issue Created)
  2. Group-defined Iterations at the parent group are able to be used by projects in subgroups and seen at the top level, even when the user does not have a role defined at the parent group. (issue created)
  3. In Group/Project Settings, Runners registered at the parent group are able to be viewed by projects in subgroups, even when the user does not have access to the parent group. Additionally, developers can use those runners.
  4. In Group/Project Settings, Group-defined CI Variables at the parent group are able to be viewed by maintainers of groups/projects, even when the user does not have access to the parent group. Additionally, developers can reference those variables in their CI Jobs.
  5. In Project Settings, Project Owners are able to select a Compliance Framework (albeit not view) parent group defined Compliance Frameworks

Intended users

User experience goal

Users would only be able to see labels when they have a role assigned to the group from where the labels are created that gives them access to see and use those labels.

Proposal

For labels defined at a group where a user has no role assigned, provide the option for a group owner or maintainer to prevent labels from being shared

Screen_Shot_2022-04-08_at_12.29.46_PM

Further details

Consider a company that partners with many other companies in writing code and oftentimes the other companies could be in competition with one another.

This is necessary when labels are leveraged for cross-departmental efforts that require segregation of duties and allows these labels to be used but only made visible to the people that are allowed to see them.

Defining labels at the sub-group levels only prevents having cross-departmental efforts.

Permissions and Security

Documentation

Availability & Testing

Available Tier

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by Tim Poffenbarger