Users with Maintainer permissions unable to create group approval rules
Summary
A user with inherited Maintainer
permissions to a project is not able to add a merge request approval rule to that project whose approvers are a subgroup.
Steps to reproduce
- Set up a group/subgroup/project structure like the following:
- Directly add users to
digital-perms-admins
withDeveloper
permissions to act as approvers. - Directly add the user that will be the merge request approval rule creator to
subgroup
as aMaintainer
. - Have that user create a merge request approval rule within
permissions-and-access
selecting thedigital-perms-admins
group as the approvers. - Observe that upon refreshing the page after creating the rule that the group is no longer listed as an approver.
- Optionally, apply the workaround, try again, and observe it works without issue.
Example Project
Replicated in approval-rule-testing group permissions-and-access project
What is the current bug behavior?
After the Maintainer
creates a merge request approval rule that contains a subgroup as approvers that rule is not saved upon refreshing the page and the avatars of the members of the group do not display in the list. When the rule is edited, the subgroup has been removed from it automatically.
What is the expected correct behavior?
Users with inherited Maintainer
permissions to a project should be able to successfully create merge request approval rules that contain subgroups as approvers, like users with Owner
permissions can.
Relevant logs and/or screenshots
Approval rule immediately after creation:
Same approval rule on refresh:
Output of checks
This bug happens on GitLab.com: 14.4.0-pre 1d8a236a037
Workaround
It seems this can be worked around by elevating the approval rule creators permissions from Maintainer
to Owner
and then back again.