Allow subgroups and projects to have higher visibility than parent group

Summary

Currently, GitLab enforces strict visibility inheritance where child namespaces (subgroups and projects) cannot have higher visibility than their parent group. This prevents customers from having a Private top-level group while allowing Internal visibility for subgroups or projects within that hierarchy.

Problem to Solve

A customer with an Ultimate license needs to:

• Keep their top-level group set to Private visibility
• Allow certain subgroups and/or projects within that group to be set to Internal visibility
• Currently, GitLab prevents this configuration, requiring them to either:
  • Change the entire top-level group to Internal (not acceptable for their security requirements)
  • Keep all child namespaces Private (too restrictive for their use case)

Customer Context

• Tier: GitLab Ultimate
• Salesforce Account: Link
• Zendesk Ticket: Link

User Experience Goal

Allow administrators to configure visibility settings for subgroups and projects independently from their parent group's visibility level, while maintaining security controls and preventing accidental exposure of private content.

Proposal

Allow Visibility Override Add a configuration option that allows subgroups and projects to have Internal visibility even when parent is Private

Benefits

1. Flexibility: Enables complex organizational structures with varying security requirements
2. Security: Maintains controls to prevent accidental public exposure
3. Compliance: Helps organizations meet specific compliance requirements
4. User Experience: Reduces friction for teams needing internal collaboration within private groups

Related Issues

• #372760 (closed) - Subgroup can not be created if parent group is private
• #374578 (closed) - Cannot create a subgroup in a private or internal group
• #343257 (closed) - Improve visibility radio option text on new project page
• #405168 (closed) - File-based group export sub-group always imports as private

Documentation

Documentation would need to be updated to cover:

• New visibility override behaviour
• Security implications and best practices
• Configuration examples
• Migration guide for existing groups

What does success look like?

• Customer can set top-level group to Private
• Customer can set subgroups/projects to Internal within that Private group
• Security controls prevent accidental public exposure
• Audit trail shows all visibility changes
• Documentation clearly explains the feature and security implications