Optionally disable group membership inheritance: MVC

Overview

In #30785 (closed), we've conducted some discovery on the path forward on electively disabling membership inheritance that's the current mandatory behavior for groups into subgroups. This issue captures the implementation path.

Since this change touches many areas of the application, we'll need to make sure we test any changes thoroughly.

Problem to Solve

Currently, subgroups inherit in total the members from the parent group. While it is possible to override the members access on subgroups (for example, give master access to someone on a subgroup who has developer on the parent group), it is not possible at the moment to remove access to members on subgroups. Some organizations have "secret" groups that should only be visible to specific project members due to compliance or because they contain sensitive information that required an NDA.

Example:

• Department
  • Group 1
  • Group 2 (Secret)
  • Group 3
  • Group 4
  • Group 5

In the scenario above, there is not a simple way to give access to all team members to Group 1, 3, 4 and 5. If SSO is set up in the Department group it is impossible since by default users would be added as a Guest in Department giving them a guest role in the entire hierarchy. We plan to solve for part of this problem with #220203 (closed) , but it would mean that explicit access would need to be given to each group making maintenance complicated. Since "secret" groups are the exception, it is much easier for administrators to mark those as excluded from inheritance and continue to take advantage of inherited permissions for every other group. Customers structure groups to reflect their internal organizational structure so being able to nest "secret" projects in the hierarchy would be ideal. Some groups can transition from "secret" to open as part of their lifecycle.

Proposal

• Implement an option on the group settings page, available only to group Owners, that allows a user to disable forced member inheritance from parent groups.
  • When enabled, all inherited members should be removed from group access and the membership of the group must be defined specifically for that group.
• This change should also remember to influence (not comprehensive):
  • Search
  • Autocompletes

In order to constrain scope, this option should only be available for top-level groups. What this means:

• Top-level group (enables this option, disabling group membership inheritance for the top-level group only)
  • Subgroup A (membership must be defined for this specific subgroup)
    • Sub-subgroup B (inherits all members from Subgroup A)
      • Sub-subgroup C (inherits all members from Subgroup A + Sub-subgroup B)
  • Subgroup D (membership must be defined for this specific subgroup)
    • Sub-subgroup E (inherits all members from Subgroup D)

Availability & Testing

This feature is high risk for existing functionality as it touches critical parts of GitLab such as authorisation. There could also be some performance implications.

Example Hierarchy:

• Top-level group
  • Subgroup A
    • Sub-subgroup B
      • Sub-subgroup C
        • Project 1
  • Subgroup D

Following should be covered with feature tests:

• Option to turn off group membership inheritance is only available to the first subgroup. Ensure that the option is not available to any levels below. For the example hierarchy above, only the Subgroup A and Subgroup D will have this option. Sub-subgroup B and Sub-subgroup C will not have this option.
• Upon disabling inheritance on a group, all inherited users will loose that group's and it subgroup's and project's access accept for the owner of the group.
• Any project or sub-group that is a child of a sub-group that does not have inheritance option due to its lower position in the hierarchy should continue to inherit members. For example, in the above hierarchy, if inheritance is disabled on Subgroup A, Sub-subgroup C should continue to inherit members of Sub-subgroup B and Project 1 should continue to inherit members of Sub-subgroup B and Sub-subgroup C.
• A user that is a member of top level group but not Subgroup A that has inheritance disabled should not see the Subgroup A (if it is a private group) and its objects (subgroups, members, labels, epics, issues etc) in search results.

And end-to-end tests that checks the inheritance before and after disabling it on a group is also recommended. Before merging, it is highly recommended to run the package-and-qa job to ensure existing end-to-end tests are do not break.

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.