Force Default Parent Group for New Group Creation

Summary

Add the ability for GitLab administrators to configure a default parent group that automatically becomes the parent for all new groups created by users, preventing the creation of new top-level groups while maintaining a clean organizational hierarchy.

Problem to solve

Currently, GitLab only provides the ability to prevent users from creating top-level groups entirely (can_create_group: false), but there's no way to automatically force all new groups to be created under a specific parent group. This creates organizational challenges where:

  1. Inconsistent hierarchy: Users can create top-level groups alongside the main organizational group
  2. Administrative overhead: Administrators must manually move groups or constantly monitor and educate users
  3. Namespace pollution: Multiple top-level groups make it difficult to maintain a clean organizational structure
  4. User friction: Users get confused about where to create their groups and teams

Proposal

Add a new instance-level configuration option that allows administrators to specify a default parent group for all new group creation:

Configuration Options

  1. Default Parent Group ID/Path: Specify which existing group should be the default parent
  2. Enforcement Level:
    • optional: Show the default parent but allow users to change it
    • required: Force all new groups to be created under the specified parent
    • disabled: Current behavior (no default parent)

User Experience

When a user creates a new group:

  • The parent group field is pre-populated with the configured default parent group
  • If enforcement is set to "required", the parent group field is read-only
  • Users can still create subgroups within their assigned groups normally

Admin Interface

Admin Area > Settings > General > Account and limit settings

☐ Prevent users from creating top-level groups
☑️ Enforce default parent group for new groups
   Default parent group: [krafton ▼]
   Enforcement level:   [Required ▼]
   
   ℹ️  When enabled, all new groups will be created as subgroups 
      under the specified parent group. Existing groups are not affected.

API Integration

{
  "default_parent_group_id": 123,
  "default_parent_group_enforcement": "required"
}

Use Cases

  1. Enterprise Organizations: Maintain all teams under a single corporate group (e.g., company/engineering, company/marketing)
  2. Educational Institutions: Keep all departments under the institution name (e.g., university/computer-science, university/physics)
  3. Service Providers: Organize client projects under the main organization (e.g., agency/client1, agency/client2)

Benefits

  • Organizational Consistency: Ensures all groups follow the same hierarchical structure
  • Reduced Administrative Overhead: Eliminates the need to manually move or monitor group creation
  • Better User Experience: Users don't need to worry about where to create groups
  • Cleaner Namespaces: Prevents namespace pollution at the top level
  • Inherited Permissions: New groups automatically inherit parent group settings and permissions

Implementation Considerations

  • Should work alongside existing can_create_group settings
  • Must respect existing group permissions and visibility levels
  • Should not affect existing groups (only apply to new group creation)
  • Need to handle cases where the default parent group is deleted or becomes inaccessible
  • Should integrate with SAML/LDAP group provisioning if applicable

Alternative Workarounds

Currently, organizations must use:

  1. Disable group creation entirely and manually create groups for users
  2. Monitor group creation and manually move groups post-creation
  3. Extensive user training and documentation

These workarounds create friction and don't scale well for larger organizations.

Related Issues

  • Similar functionality exists in other GitLab features (default branch protection, default project settings)

Acceptance Criteria

  • Administrator can configure a default parent group for new group creation
  • Administrator can choose enforcement level (optional/required/disabled)
  • Users see the default parent group pre-selected when creating new groups
  • When enforcement is "required", users cannot change the parent group
  • API supports the new configuration options
  • Existing groups are not affected by this setting
  • Feature works with existing group permissions and visibility settings
Edited by Christina Lohr