Support custom roles in merge request approval policies (#13550) · Epics · GitLab.org

Support custom roles in merge request approval policies

### Release notes We’ve expanded the flexibility of merge request (MR) approval workflows by adding **support for custom roles** in approval policies. This enhancement allows organizations to fine-tune their code review and security processes by defining and applying approval requirements based on custom roles. You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals. ### Problem to solve As we introduce new custom roles, merge request approval policies could provide more granular support for defining these roles within an action. For example - when a security finding is detected, require approval from 2 users with `custom security team role`. ``` type: approval_policy actions: - type: require_approval approvals_required: 1 role_approvers: - maintainer - owner - 1002476 ``` As an example, I've created a custom role with relevant, available permissions today: ![image.png](/uploads/f4b678fb3eb9dde1dd23586ccee71238/image.png) Within our existing approval action options, we'd want to add support for choosing a custom role from the available. ### Intended users ### User experience goal We can leverage existing UX to show default vs custom roles: | Custom role dropdown | MR approval policy current state | |----------------------|----------------------------------| | ![image.png](/uploads/719c67ddacce26d34beb217eb07c7181/image.png) | ![image.png](/uploads/7edd1a6d88292d789817cc3ddefd6f84/image.png) | ### Proposal 1. As GitLab introduces new custom roles, automatically populate them into merge request approval policies as an option. 2. When a user creates a custom role with their own permissions, populate them into merge request approval policies as an option. 3. Grey out any custom roles that do not have permission to approve MRs, as they will inherently not be eligible to approve. Instead of filtering, list options, but indicate which roles can be selected due to the permissions requirements. Document this limitation for users leveraging YAML to update policies. 4. Regularly check that custom roles configured as approvers in a policy still have permissions. Warn users in the policy editor UI if there are potential configuration errors. ### Further details 1. We may need to consider impacts of roles being modified either by GitLab or users, and how that impacts existing policies defined with a custom role. 2. Custom roles can be created at an instance level or in top-level groups. If policies are being enforced across top-level groups for self-managed customers, there could be a scenario where the role defined in the policy does not exist in the top-level group. ### Permissions and Security ### Documentation ### Availability & Testing ### Available Tier ### Feature Usage Metrics ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### What is the competitive advantage or differentiation for this feature? ### Links / references  _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._   _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._   *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*

epic