<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=438323) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal Add new instance-level settings that allow administrators to disable Pull, Push, and/or Bidirectional mirroring UI options independently for compliance purposes, while keeping existing mirrors functional. #### Problem Statement Organizations with compliance requirements need the ability to disable specific repository mirroring options at the instance level while still allowing existing mirrors to function. Currently, there is no way to prevent users from creating new mirrors of specific types through the GitLab UI for compliance purposes. #### Proposed Solution Add new instance-level application settings that: 1. **Provide granular control** - independently disable Pull, Push, and/or Bidirectional mirroring UI options 2. **Hide UI options** for creating new mirrors of disabled types in project settings 3. **Preserve existing functionality** - existing mirrors continue to work normally regardless of UI settings 4. **Provide clear messaging** when options are disabled #### Related Documentation - [Repository mirroring documentation](https://docs.gitlab.com/ee/user/project/repository/mirror/) - [Bidirectional mirroring](https://docs.gitlab.com/ee/user/project/repository/mirror/bidirectional.html) <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->