Unable to add group members with inherited membership to group-level protected environments via the UI

Summary

When attempting to add group members to group-level protected environments via the UI, users with only inherited membership do not appear in the "Allowed to deploy" or "Approvers" dropdowns. However, these users can still be added via the API, which suggests that this should also be possible in the UI.

Please note that inherited members do appear in the dropdowns for project-level protected environments, indicating an inconsistency between group and project levels.

Steps to reproduce

  1. Navigate to Settings > CI/CD > Protected Environments at the group level.
  2. Click Expand to manage protected environments.
  3. Attempt to add a group member with inherited membership to the "Allowed to deploy" or "Approvers" list.
  4. Observe that only users with direct membership appear in the dropdown, while those with inherited access are missing.

What is the current bug behavior?

Users with inherited group membership do not appear in the dropdown selection for "Allowed to deploy" or "Approvers". These users can still be added via the API, confirming they have the necessary permissions but are not recognized in the UI.

What is the expected correct behavior?

Users with inherited group membership should appear in the dropdown selection, just as users with direct membership do. The UI should align with API behavior, allowing inherited members to be selected without requiring direct membership.

Output of checks

This bug happens on GitLab.com

Implementation guide

  1. Introduce a new prop called inherited (non-required, default to false) to the access_dropdown
  2. Provide the prop to the getUsers method
  3. Update access_dropdown_api to use new prop and provide it to getGroupMembers instead of the hardcoded false.
  4. Set this prop within the create_protected_environment component.
Edited by Anna Vovchenko