## 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: ```ruby 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](https://gitlab.com/groups/gitlab-org/-/epics/9025) 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`: ```ruby 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