Allow group with inherited permissions to be used in Protected Environments rules
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Currently we can only use groups(and prabably project members) who are directly members of the project in the protected environments. (Both in UI and API)
It would be convenient for users to be able to configure protected environments with approvals required from the group which is not directly added to the project, but added to the parent group.
This was a typebug initially, but changed to a feature request.
See original description
When attempting to add a group (with inherited permission) to a project's Protected Environment as approvers via API, users are presented with an error {"error":"deploy_access_levels is invalid"}. If the group is explicitly added as a member of the project, the addition will succeed.
Steps to reproduce
Create a project within a group groupA and authorize another group groupB to groupA but not explicitly to the project. When attempting to add groupA to the list of approvers for the project's Protected Environment, you'll receive the error above.
If groupA is explicitly added to the project, adding it as approver for the same protected environment works.
Desired Behavior
This should work similarly to Protected Branches (which do respect inherited permissions). It's worth noting that a check against inheritance_disabled as described in #33534 (closed) may be necessary.
Example Project
WIP
Relevant logs and/or screenshots
Failed attempt
REQUEST:
curl --request POST --header "PRIVATE-TOKEN: $TOKEN" 'https://gitlab.com/api/v4/projects/12345/protected_environments?name=example&deploy_access_levels%5B40%5D%5Bgroup_id%5D=1234'RESULT: {"error":"deploy_access_levels is invalid"}%
Successful attempt
REQUEST:
curl --request POST --header "PRIVATE-TOKEN: $TOKEN" 'https://gitlab.com/api/v4/projects/12345/protected_environments?name=example&deploy_access_levels%5B%5D%5Bgroup_id%5D=1234'RESULT {"name":"PROD02","deploy_access_levels":[{"access_level":40,"access_level_description":"example-only","user_id":null,"group_id":1234}]}%
Output of checks
This bug happens on GitLab.com
/cc @pschwar1