Approve button disappears when branch is protected at group level (inherited setting)

Summary

When using the "Enable approval permissions for additional users" feature, the Approve button and /approve quick action stop working once the target branch is protected at the group level (inherited setting).

The MR approval rule is still visible and the approver avatars are still shown, but the Approve button disappears entirely and /approve has no effect.

Additionally, attempting to create a project-level protected branch rule to work around this silently fails — the MR approval rule is not saved.

Related issue: #506733

Steps to Reproduce

  1. Follow the Enable approval permissions for additional users guide — add a user with Reporter role as an approver. Confirm the Approve button is visible and works.
  2. Protect the branch at the group level (e.g. main/default branch) so the protection is inherited by the project (Setting inherited).
  3. (Skip if the group protection was already in place before the project was created.) If the branch was already protected at project level, go to the project branch rules and delete the project-level protected branch rule, leaving only the group-level rule.
  4. Refresh the MR.
  5. Observe: the Approve button is gone. The /approve quick action also has no effect. The approval rule and approver avatars are still displayed.

Note: Creating a project-level protected branch rule does not fix the behaviour — it silently fails to save the MR approval rule.

Current Behavior

Once the branch is protected at group level (inherited), the Approve button disappears from the MR and the /approve quick action no longer works. The approval rule and approver avatars remain visible.

image image

Expected Behavior

The Approve button and /approve quick action should remain functional for users explicitly granted approval permissions via the MR approval rule, regardless of whether the branch protection is set at project or group level.

Workaround

The following workaround has been confirmed to restore the behaviour:

  1. Remove the branch protection at group level.
  2. In the project, create the protected branch rule.
  3. Add the MR approval rule (in the project branch rule).
  4. Re-add the group-level protected branch.

This workaround further suggests this is a bug rather than intentional behaviour.

Environment

  • GitLab Version: GitLab.com (SaaS)
  • Deployment Type: GitLab.com

Impact

This blocks users from approving MRs when their organisation relies on group-level branch protections — a common setup for organisations migrating to GitLab that require approvers to not have write access to repositories.

Edited by Ségolène Bouly