Skip to content

Optionally disable inheritance

Problem

Currently user inheritance follows a strict hierarchical pattern where a member added to a group inherits to all subsequent groups and projects. There is no way to turn off the inheritance. This creates several problems:

  • Users cannot add a member to a specific group only, without that member inheriting into all of the subsequent groups or projects
  • There is no way to create a project that does not also contain all the members from parent groups (often the entire company) due to inheritance

Proposal

Solution 1 - Members only

As a follow-up to this proposal, groups and projects would have an option for Members only, meaning that these groups or projects only contain direct members. Members could not inherit into these groups or projects. For the case of groups, we would have to define what this option means for the subgroups and projects it contains, as inheritance cannot work in a way that it skips a level. This means inheritance would be broken at the level that it is enabled on, which would then apply to all the objects below as well.

The MVC for this solution could be to enable Members only on the project level only.

Solution 2 - Teams

Another logical consequence of this proposal could be to separate the groups used to organize team members from the groups used to organize projects, so that:

graph TD
  Top-level_group --> Project_group --> Project_1
  Top-level_group --> Team_group --> Team_1

Teams could still be built hierarchically, meaning team members would inherit into subsequent teams. Specific teams would then be shared into the groups or projects that they need to be members of.

Advantages

  • To some extent this is already possible today by using group sharing.

Disadvantages

  • Migration effort to restructure current setup.
  • Resolution of current gaps in group sharing is needed.
  • Some thought would need to go into setting up the Team structure to avoid situations like "I want this team to join this project, except for this particular member." which could then result in the team being duplicated.

Solution 3 - SSO SAML Group Links

Use the feature SSO SAML Group Links, that enables users to create specific groups in their AD to assign specific rights to the desired folder level. This takes place by creating a claims transformation into a company's Identity providers to send the “Groups” to Gitlab. Each group can then be assigned to a rights level in GitLab into a specific folder.

Advantages

  • Flexibility: When a member is moving internally to another position, if the changes are made into the Identity Provider nothing would have to be done manually, the changes would be reflected in GitLab automatically at next login.

Disadvantages

  • Lack of visibility and control on groups
  • Might add a level of complexity when onboarding employees
  • Requires changes in current structure
  • AD Group management speed might have an effect
  • Inability to show who has access to projects without the help of internal IT department as it is AD group based

Solution 4 - Selective Inheritance with Legacy Mode

Implement a hybrid approach that maintains backward compatibility while introducing granular controls:

  1. Add a new inheritance_mode setting at both group and project levels with three options:
    • legacy (default): Current behavior with full inheritance
    • selective: Enables granular inheritance control
    • isolated: No inheritance, direct members only
  2. When selective mode is enabled:
    • New "Inherit Access" toggle appears for each member/group
    • Default is "inherited = true" for backward compatibility
    • Can be toggled per member/group
    • Changes only affect downstream inheritance

Migration Strategy

  1. All existing groups/projects default to legacy mode
  2. Administrators can opt-in to selective mode per group/project
  3. When switching to selective:
  • All existing members retain inheritance by default
  • New UI controls appear for managing inheritance
  • Can gradually adjust inheritance per member

Advantages

  • Backward Compatibility
    • No disruption to existing setups
    • Opt-in basis for new features
    • Gradual migration path
  • Flexibility
    • Granular per-member control
    • Multiple inheritance models supported
    • Can mix approaches as needed
  • Maintainability
    • Clean separation of concerns
    • Clear upgrade path
    • Minimal technical debt

Open Questions

  • Is it necessary to disable inheritance at the group level? What are the use cases? Could this be applied to projects only?
Edited by Christina Lohr