[go: up one dir, main page]
Skip to content

Only the newest subgroup with identical name can be added as approver on an MR rule

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

If more than one subgroup with the same name (e.g., Dev / Managers and QA / Managers) has been invited to a project, only the most recently created of those subgroups can be added as an approver on a merge request rule in the UI. Selecting any of the other subgroups with a matching name just adds the newest subgroup with that name as an approver. You can add the newest subgroup repeatedly by re-selecting any of the other subgroups from the dropdown.

When updating an MR rule via the REST API, this bug doesn't occur.

Steps to reproduce

  1. Create a top-level group (group-a).
  2. Add a subgroup within it (group-a/subgroup).
  3. Invite a user to the subgroup with the Maintainer role.
  4. Repeat steps 1-3 with group name group-b.
  5. Repeat steps 1-3 with group name group-c.
  6. Create a top-level namespace for the target project (target-group)
  7. Create a target project within the new namespace (target-group/target-project)
  8. Invite group-a/subgroup, group-b/subgroup, and group-c/subgroup to the target project.
  9. Go to the project's Settings > Merge requests > Merge request approvals > Approval rules and select Add approval rule.
  10. In the Add approval rule side panel...
  11. Name the rule (Test rule)
  12. Under Groups, attempt to add group-a/subgroup and group-b/subgroup. You should observe the following:
    • group-c/subgroup is added
    • When you attempt to add another group, group-a/subgroup and group-b/subgroup are still listed in the dropdown, but group-c/subgroup isn't anymore.
    • If you try to add group-a/subgroup or group-b/subgroup again, group-c/subgroup is listed again under added groups.
    • If you uninvite group-c/subgroup from the project, the same behavior occurs except with group-b/subgroup as the subgroup that overrides group-a/subgroup.

Example Project

What is the current bug behavior?

If more than one subgroup with the same name has been invited to the project, only one of them can be added as an approver on a merge request rule. The subgroup that can be added is always the one most recently created.

What is the expected correct behavior?

If more than one subgroup with the same name has been invited to the project, any of those subgroups can be added as an approver on a merge request rule.

Relevant logs and/or screenshots

In the logs, this looks like successful POST requests to api/:version/projects/:id/approval_rules / PUT requests to /api/:version/projects/:id/approval_rules/:approval_rule_id, with the name and ID of the newest subgroup.

As shown in the video above, this bug allows you to add the newest subgroup with a matching name as many times as you want. If you save the rule after adding the newest subgroup three times, for example, the POST / PUT request will include the subgroup three times:

      "key": "groups",
      "value": [
        23,
        18,
        17,
        23,
        23
      ]

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Workarounds

  • If you rename a subgroup so that it doesn't match the name of any other subgroup invited to the project, you can add it as an approver to a MR rule without a problem. After adding the subgroup as an approver, you can rename the subgroup back to the old name.
  • The Project-level MR approvals API doesn't have this bug. The downside is, if you're updating an existing rule with the API, you have to include every individual approver and group that was already attached to the rule, along with the subgroup you want to add. If you don't list an existing approver in an update request via the API (PUT /projects/:id/approval_rules/:approval_rule_id), that approver is removed from the rule. Example request:
 curl --request PUT \
	--header "PRIVATE-TOKEN: <token>" \
	--header "Content-Type: application/json" \
	--data '{"approvals_required":1, "name":"My MR approval rule", "group_ids":[23, 19], "user_ids":[1, 2, 3]}' "https://gitlab.example.com/api/v4/projects/:project_id/approval_rules/:approval_rule_id"
Edited by 🤖 GitLab Bot 🤖