Support Approval Rules in Deployment Approval UI
Release notes
In this release, we are adding additional key information for multiple approval rules in the approval UI. Now during the workflow of approving a deployment, you can see who has already approved and how many approvals are still needed and from which groups. This key information enables transparency and context for making the approval decision and also ensures compliance during an audit review.
Problem
In the initial MVC, both Deployment Executors and Deployment Approvers were managed in the same access level. This could be a problem that Approvers can accidentally gain an access to the critical environment, where they are supposed to approve/reject only. To resolve the problem, we should separate access levels between executors and approvers. For example:
- Production Environment:
- Who can deploy?: @operator-group
- Needs approval for deployment?:
- At least one approval from @qa-tester-group
- At least one approval from @security-group
In the previous issue, we added a API-basis support for the Multi Access Levels. In this issue, we extend the feature to frontend part, so that users can easily interact with the multi access levels.
Design
- Add in table with approvers, approvals, approved by to give those viewing the modal the appropriate information and history behind who has approved, and who still needs to approve.
- Not in scope for this issue: Cleaning up the comments section will be done in Enhance comment section in Deployment Approval ... (#372377 - closed)
New Modal |
---|
![]() |
- Note: The Modal is getting busy! Moving information out of the modal will be handled in: Deployment Detail Page (or Deployment Request s... (#360503)
- Modal with all variations can be found here.
Figma File
Technical Proposal
- For the project with Multiple Approval Rules, we show the proposed interface.
- We can send this flag to frontend via EnvironmentHelper.
- Condition:
deployment.environment.required_approval_count > 0 && deployment.environment.has_approval_rules? == true
- Condition:
- If this is true, frontend requests to the GraphQL query. Alternatively, frontend can call Public API, however, it doesn't include user avators.
- We can send this flag to frontend via EnvironmentHelper.
- For the project with Unified Approval Setting, we show the previous interface.
- I think this is necessary to avoid the disturbance in existing projects.
- We can send this flag to frontend via EnvironmentHelper.
- Condition:
deployment.environment.required_approval_count > 0 && deployment.environment.has_approval_rules? == false
- Condition:
- If this is true, frontend fetches the data from
deployment_approval_data
(i.e. no change) - Reference: https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/helpers/ee/environments_helper.rb
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.