Allow admins to scope admin-level MR approval settings to compliance-labeled projects

Problem to solve

With the iterative implementation of #39060 (closed) we did not provide a suitable way to control the scope of these settings. When enabling these settings, they are inherited by all projects in an instance. Organizations with regulated projects tend to also have projects that are not regulated and therefore should not inherit these strict controls.

Problem: As an administrator, I want to be able to selectively apply these controls only to regulated projects, so that I can retain flexibility for my teams in unregulated projects while still meeting my compliance requirements.

Intended users

Further details

After implementing #39060 (closed), we're now focused on narrowing the scope of these settings (currently applies to all projects in an instance) to allow for more granular control. Not all projects in a GitLab instance are regulated for all users. In many cases, only a subset of projects need stringent controls in place for MR approvals.

Before we can implement this feature, we'll need to ship #118671 (closed) so we have a signal with which to refine the scope of these settings.

Proposal

Add an optional selection criteria to #39060 (closed) to allow admins to specify what compliance projects to inherit the settings to. For example:

  • Enable approvals by the author
    • 🚥 Allow a merge request author to approve their own merge requests.
  • Enable approval by committers
    • 🚥 Allow a merge request committer to approve the merge request they've committed.
  • Enable approvers list modification
    • 🚥 Allow owners and maintainers to modify the approver list for merge requests and override approvals at the individual merge request level.

These settings will apply to all projects unless you limit the scope to specific project compliance labels:

  • SOX
  • PCI-DSS
  • HIPAA

Prototype and Mockups

Figma prototype

Group_16

Permissions and Security

Only administrators can access and modify this setting

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Daniel Mora