Skip to content

Groups appear in invitation dropdown but fail with 404 error due to inconsistent permissions

Problem Summary

GitLab currently has inconsistent and overly restrictive permission checks when inviting groups to projects, preventing legitimate collaboration scenarios and creating a poor user experience. The core issue stems from a mismatch between visibility permissions (:read_group) and invitation permissions (:read_namespace).

Primary issue

Users can see groups in the invitation dropdown but receive a 404 "Not found" error when attempting to invite those groups to their projects. This creates a confusing user experience where the system appears to offer functionality it cannot deliver.

Specific scenarios that fail

  1. Cross-team collaboration: Users who are members of projects within a group (but not group members themselves) cannot invite that group to their own projects
  2. Freelancer/contractor integration: Team leads cannot invite contractor groups to projects without first joining those groups
  3. Self-service access management: Teams cannot independently manage access to their repositories without admin intervention

Root cause analysis

The permission system has two different checks:

  • :read_group - Controls group visibility in dropdowns (includes projects visibility check)
  • :read_namespace - Controls actual group invitation capability (more restrictive)

The inconsistency occurs because :read_group returns true when a user has access to projects within a group (due to the has_projects policy rule), but :read_namespace returns false for the same scenario.

Impact

User experience issues

  • Confusing interface: Groups appear selectable but fail upon invitation
  • Workflow disruption: Forces users to request admin intervention or join groups unnecessarily
  • Reduced autonomy: Teams cannot self-manage access to their projects

Business impact

  • Reduced collaboration efficiency: Teams cannot quickly onboard external collaborators
  • Increased administrative overhead: Admins must manually handle routine access requests
  • Scalability concerns: Current model doesn't scale for organizations with many teams and projects

Current workarounds

  • Users must join groups they want to invite (defeats purpose of group-based permissions)
  • GitLab admins must manually handle all cross-group invitations
  • Teams resort to individual user invitations instead of group invitations

Proposed Solutions

Option 1: Align permission checks

Modify the group policy to ensure :read_namespace is enabled whenever :read_group is enabled:

rule { can?(:read_group) }.policy do
  enable :read_milestone
  enable :read_issue_board_list
  enable :read_label
  enable :read_issue_board
  enable :read_group_member
  enable :read_custom_emoji
  enable :read_counts
  enable :read_namespace  # Add this line
end

Pros:

  • Simple, consistent fix
  • Maintains existing security model
  • Eliminates UI/functionality mismatch

Cons:

  • May need security review to ensure no unintended access expansion

Option 2: Enhanced invitation workflow with approval

Implement a request-approval system where:

  • Users can invite any visible group
  • Group owners/maintainers receive approval requests
  • Automated approval for certain trust relationships

Pros:

  • Enables self-service while maintaining security
  • Provides audit trail
  • Flexible approval workflows

Cons:

  • More complex implementation
  • Requires UX design for approval interface
  • May introduce notification overhead

Option 3: Expand group visibility rules

Modify the :read_namespace check to include the same project-based visibility logic as :read_group:

rule { has_projects }.policy do
  enable :read_group
  enable :read_namespace  # Add this line
end

Pros:

  • Directly addresses the root cause
  • Minimal code change
  • Maintains current security boundaries

Cons:

  • May have broader implications for namespace permissions

Recommendation

Option 1 is recommended as the primary solution because:

  • It creates consistency between visibility and invitation permissions
  • It's the least risky approach from a security perspective
  • It solves the immediate user experience problem
  • It can be implemented quickly and safely

Option 2 could be considered as a future enhancement to provide even more flexible collaboration workflows while maintaining security controls.

Success Criteria

  1. Users can successfully invite any group they can see in the dropdown
  2. No 404 errors when inviting visible groups
  3. Existing security boundaries are maintained
  4. Cross-team collaboration scenarios work seamlessly
Edited by Christina Lohr