Inconsistent user role requirements between project and group-level protected environments

Summary

There is an undocumented discrepancy between project-level and group-level protected environments regarding which user roles can be added to the "Allowed to deploy" list. The system silently rejects attempts to add Developer-role users to group-level protected environments without providing error messages or documentation about this restriction.

Current Behavior

Project-level protected environments:

• Users with Developer permissions or higher can be added to "Allowed to deploy" list
• This behavior is documented and working as expected

Group-level protected environments:

• Only users with Maintainer or Owner permissions can be added to "Allowed to deploy" list
• Developer-role users are silently rejected without error messages
• This restriction is not documented anywhere

Expected Behavior

Either:

1. Consistent behavior: Allow Developer-role users in group-level protected environments (same as project-level)
2. Clear documentation: Document the restriction and provide clear error messages when attempting to add ineligible users

Steps to Reproduce

1. Navigate to a group's Settings > CI/CD > Protected Environments
2. Create or edit a protected environment
3. In the "Allowed to deploy" dropdown, attempt to add a user with Developer role
4. Observe that the user appears in search but cannot be successfully added
5. No error message is displayed explaining why the addition failed

Code Evidence

The discrepancy exists in the codebase at: File: ee/app/services/protected_environments/base_service.rb (lines 58-64)

def qualified_user_ids
  if project_container?
    container.project_authorizations
      .visible_to_user_and_access_level(user_ids, Gitlab::Access::DEVELOPER)
      
  elsif group_container?
    container.members_with_parents.owners_and_maintainers
  end.pluck_user_ids.to_set
end

Analysis:

• Project-level: Accepts users with DEVELOPER access level or higher
• Group-level: Only accepts owners_and_maintainers (excludes Developers)

Impact

User Experience Issues:

• Confusing silent failures when adding Developer users
• Inconsistent behavior between project and group levels
• No guidance on why certain users cannot be added

Documentation Gap:

• Current documentation doesn't mention this role restriction for group-level environments
• Users expect consistent behavior across project and group levels

Additional Context

This issue affects organizations that:

• Use group-level protected environments for consistency
• Have team members with Developer roles who need deployment access
• Expect consistent permission models across GitLab features

Acceptance Criteria

• Behavior is consistent between project-level and group-level protected environments OR
• Restriction is clearly documented with reasoning
• Clear error messages are shown when adding ineligible users
• UI indicates role requirements before user attempts to add someone