Subgroups are not presented in "Allowed to deploy" dropdown for group-level protected environments

Summary

Given a group structure like this:

• main
  • users
    • developers
    • deployers

Only the users group will be available for selection in the Allowed to deploy dropdown of a group-level protected environment. Using the corresponding API endpoint you can set the sub-subgroups (developers, deployers).

Steps to reproduce

1. Create group main
2. Create sub-group users
3. Create sub-subgroups developers and deployers
4. Navigate to group level CI/CD settings for `main group
5. Create new protected environment
6. Observe only users group being selectable
7. Use https://docs.gitlab.com/ee/api/group_protected_environments.html#protect-a-single-environment to create protected environment in main group with the developers group being Allowed to deploy
8. Observe UI glitch in list of protected environments UI at the group level CI/CD settings

Example Project

https://gitlab.com/groups/gl-demo-premium-mgrabowski/zd-449664

What is the current bug behavior?

Not all relevant groups are selectable in UI

What is the expected correct behavior?

All relevant groups are selectable in UI

Relevant logs and/or screenshots

Only the direct subgroup users can be selected. The left side shows the group level CI/CD settings of the zd-449664 group where I reproduced this – it is the main group from this issue description.

---

The sub-subgroups can be used via API call. It looks like this in the UI afterwards, though. (production was protected via API with the deployers sub-subgroup, staging was protected via the UI with the users group.)

Output of checks

This bug happens on GitLab.com

Possible fixes

Invited group is not shown in "Allowed to" drop... (#345140 - closed) seems to be a slightly more complex version of this, which was resolved via Update access dropdowns to include related groups (!130768 - merged) just a few days ago. It sounds like it should have already fixed this – but I can still reproduce it as of right now. I think it might only have been fixed for the project level, not the group level.

Technical Proposal

Backend

Add params to the /-/autocomplete/group_subgroups.json endpoint to return sub-subgroups as well.

• Add support for including group.shared_with_groups in the GroupsFinder. The GroupsFinder returns a union of different queries based on the parameters. We should support a new parameter (ie: include_shared_with_groups) and add the group.shared_with_groups in the union of queries.
• GroupsFinder is used by Autocomplete::GroupSubgroupsFinder, which in turn is used by EE::AutocompleteController#group_subgroups, which is then what's called in the frontend.

Frontend

Pass additional params to getSubGroups in app/assets/javascripts/groups/settings/api/access_dropdown_api.js to ensure the fetching of sub-subgroups