Group Iterations 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 iterations 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 Labels 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 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)
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

A good example of how this is counter to GitLab model are that Group Milestones work as expected, unlike Iterations, Epics & Labels.

Intended users

• Parker (Product Manager)

User experience goal

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

Proposal

For iterations defined at a group where a user has no role assigned, provide the option for a group owner or maintainer to prevent epics from being usable/viewable in the group's subgroups.

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 iterations are leveraged for cross-departmental efforts that require segregation of duties and allows these iterations to be used but only made visible to the people that are allowed to see them.

Defining iterations 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.