### Summary A maintainer of a project can modify MR approval settings even when a [security policy](https://docs.gitlab.com/user/application_security/policies/) including `approval_settings.remove_approvals_with_new_commit=true` overrides it. Whatever a maintainer updates the "When a commit is added" setting to will be ignored, which is confusing behaviour. It makes the maintainer think there is a bug in revoking approvals, when really it's a UI issue. ### Steps to reproduce <details> <summary>Click to expand</summary> ## Setup - Set up `CODEOWNERS` file. - Set up security policy to require 1 approval on MR's with the option enabled: `approval_settings.remove_approvals_with_new_commit=true` - Set up branch rule for `main` to require `CODEOWNERS` approval. - Go to merge request approvals > "When a commit is added". Observe that this option is not greyed out even though the security policy above applies. Select the setting "Remove approvals by Code Owners if their files changed" and click "Save changes". {width=464 height=179} ## Repro - On a branch, make changes to a file affecting a specific code owner. - Open an MR - Observe that the MR requires approval from said code owner. - Have said code owner approve the MR. - Observe that MR is ready to merge. - Make a change unrelated to the code owner dir and push commit - Observe that pushing the commit resets approvals, even though owned code was not affected. </details> ### Example Project We're using ultimate self-hosted, so we don't have access to the needed features on gitlab.com. https://staging.gitlab.com/govern-team-test/alexander-test-group/rails-application/-/settings/merge_requests ### What is the current *bug* behavior? Pushing a commit resets all approvals even though the setting "Remove approvals by Code Owners if their files changed" is enabled (from the perspective of the project maintainer). ### What is the expected *correct* behavior? Project maintainers should not be able to modify the "When a commit is added" setting when a security policy overrides it. Similarly to how some of the approval settings are greyed out: {width=620 height=194} ### Relevant logs and/or screenshots ### Output of checks #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> System information System: Ubuntu 24.04 Proxy: no Current User: git Using RVM: no Ruby Version: 3.2.8 Gem Version: 3.7.1 Bundler Version:2.7.1 Rake Version: 13.0.6 Redis Version: 7.2.11 Sidekiq Version:7.3.9 Go Version: unknown GitLab information Version: 18.8.4-ee Revision: 24b860ec8f9 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 16.9 URL: REDACTED HTTP Clone URL: REDACTED SSH Clone URL: REDACTED Elasticsearch: yes Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: openid_connect GitLab Shell Version: 14.45.5 Repository storages: - default: tcp://REDACTED GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: REDACTED - default Version: 18.8.4 - default Git Version: 2.52.GIT </pre> </details> #### Results of GitLab application Check All good. ### Possible fixes This is highly related to #482638. This issue is requesting specifically greying out the UI options so that it does not appear as a bug. EDIT by @aturinske (2026/04/09): We could not do this; see https://gitlab.com/gitlab-org/gitlab/-/work_items/590825#note_3238466447 for context. Instead a warning icon was added after the setting ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->