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.
- Sidney (Systems Administrator)
- The management stakeholders who adhere to any auditing process. To be defined in a new Compliance Persona
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.
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:
Permissions and Security
administrators can access and modify this setting