## UX Theme When the user has setup a security approval policy(scan result policy), they should be informed properly about the different statuses on an MR page; **By clarify what's happening: why the MR is blocked, we are helping users moving faster, resolve the right problem in order, so the MR can get merged** details please the following situations: <table> <tr> <th>When triggering the problem (Confidence-Priority)</th> <th>Problem: Current Behavior</th> <th>User feedback searches</th> <th>Proposed Next step</th> <th>Rated-issue</th> <th>Progress status</th> </tr> <tr> <td> **Situation-1**: Pipeline is running & Policy is required (High-High) </td> <td>We give the user the wrong information: We tell the user MR is blocked because of approval rules(security policy); what is required is that the user needs to wait for the pipeline to finish. The current text confuses users because it simply states that all approvals must be given. Then once the pipeline finishes, if no vulnerabilities are found, this message suddenly goes away. The end user is left feeling confused why suddenly they can merge when no one approved the MR during that time</td> <td> 1\.[Detail of direct user feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/379194/#background-message-from-customer "Discussion for #374602 , Situation 1 Clarify security policy states while pipeline is running")<br>[2.Detail of the severity of the problem- logical analysis](https://gitlab.com/gitlab-org/gitlab/-/issues/379194/#problem "Discussion for #374602 , Situation 1 Clarify security policy states while pipeline is running") </td> <td>We need to reach an agreement on what the MVC is (Clarify the messaging) and there is a need for developing a bigger change (Move security policy as a separate Merge check)</td> <td> [1.Discussion issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379194/#problem "Discussion for #374602 , Situation 1 Clarify security policy states while pipeline is running") <br>[2.Original design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/370117 "🎨 Design: Clarify the state of security approvals while the pipeline is still running") </td> <td> :white_check_mark: Problem is clear and agreed<br>-> :white_check_mark: decide to move on with a design idea, need to explore more design options -> :white_check_mark: Collection of different status quo for designs -> **(Now) A research for according affordance** </td> </tr> <tr> <td> **Situation-4**: Dead-end rule: required approval number is larger than a number of approvers (High-?) </td> <td> It is possible for ALL approvals to end up in a situation where their conditions cannot be satisfied. When this happens, we simply mark the rule as `Invalid` and allow the code to be merged. This behaviour may be acceptable for regular approval rules, but failing open like this is not acceptable for security rules. Because users need to meet strict compliance regulations, they need these rules to "fail closed" and block the merge request until the rule is fixed. We need to design better messaging for this scenario. </td> <td> We can logically prove that this will block users; we don't have user feedback yet, because this is an edge case, details, please see the [discussion issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379213 "Discussion for #374602 Situation 4 invalid approver configurations") </td> <td>We need to reach an agreement on what the solution is. This is an edge case, but we need to solve it for users</td> <td> [1.Discussion issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379213 "Discussion for #374602 Situation 4 invalid approver configurations") <br>2.Original design issue </td> <td> :white_check_mark: Problem is clear and agreed. <br>**-> (Now) split into two issues:** https://gitlab.com/gitlab-org/gitlab/-/issues/389905 and https://gitlab.com/gitlab-org/gitlab/-/issues/389910 </td> </tr> <tr> <td> **Situation-2&3**: What to prioritize among all merge checks? and among all approval rules (Medium -?) </td> <td> Security policy is one of the approval rules, approval rules is one of the merge checks. We display by default one merge check at a time; in situations-2&3, there is a potential that the user wants to prioritise the security policy approval above other approval rules, and prioritise. <br>Situation 2: Should code conflict be more important than Security policy approval? <br>Situation 2: Security policy approval as recommended to solve compare to other approval rules </td> <td> We hear promoting security approval rules should be prioritised from [user interviews](https://dovetailapp.com/tags/xdL6f4PJ2xBRrF7nH5haQ), and we keep hearing similar things from the customer. Unfortunately, those are not recorded </td> <td>We need to do further problem validation research</td> <td> [1.Discussion issue](https://gitlab.com/gitlab-org/gitlab/-/issues/379211 "Discussion for #374602 Situation 2 and Situation 3 Security policy first") <br>[2.Original design issue for situation3 ](https://gitlab.com/gitlab-org/gitlab/-/issues/371325 "🎨 Design: Allow users to prioritise security approval as first things in MR which needs to be checked")<br>[2.Original design issue for situation 2](https://gitlab.com/gitlab-org/gitlab/-/issues/38025 "Security Gate: When both merge conflicts and a security approvals are blocking the MR") </td> <td> :white_check_mark: Problem is clear and agreed -> probably the design solution in situation 1 will cover this! </td> </tr> <tr> <td> **Situation-5**: When required scan job get disabled (High-High) </td> <td>Users can circumvent the scan result policy requirements if they remove the scans as part of their MR. For example, if a policy requires approval if any Criticals are found by a SAST scan, we don't find any criticals if the SAST scan does not run. We need to start checking to see whether or not the required scans have run as part of the policy and then we need to design some way to explain to the user why the merge request is blocked if the required scans have not been run.</td> <td>We hear from customers constantly calls that this is required; we shouldn't remove the policy if the scan is not enabled</td> <td>We need to reach an agreement on what the solution is. This is an edge case, but we need to solve it for users</td> <td> [Original design issue for situation 5](https://gitlab.com/gitlab-org/gitlab/-/issues/37239 "Security Approvals not required when scans removed in MR") </td> <td> :white_check_mark: Design change in policy settings page, done </td> </tr> </table> ### Beneficiary - ~"Persona: Security Analyst" - ~"Persona: Compliance Manager" #### Need & JTBD - **JTBD:** As an application security engineer, I need to be able to configure approval policies that align with my organization's requirements so that I can avoid blocking approvals unnecessarily. #### Business objective Drive Ultimate revenue by expanding the number of organisations using Scan Result policies properly. ### Confidence See the table above ### Subthemes See the table above #### Feature/solution subthemes/Discussions * [ ] [Situation 1-When pipeline is incomplete and there is a security policy enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/379194 "Discussion for #374602 , Situation 1 Clarify security policy states while pipeline is running") * [ ] [Situation 2-There is a code conflict, and approvals need](https://gitlab.com/gitlab-org/gitlab/-/issues/379211 "Discussion for #374602 Situation 2 and Situation 3 Security policy first") * [ ] [Situation 3-There are multiple rules (including security rules)](https://gitlab.com/gitlab-org/gitlab/-/issues/379213 "Discussion for #374602 Situation 4 invalid approver configurations") * [ ] [Situation 4- It is a dead-end role](https://gitlab.com/gitlab-org/gitlab/-/issues/379213 "Discussion for #374602 Situation 4 invalid approver configurations") **Prioritized list of design issues in this theme:** <table> <tr> <th>Priority</th> <th>Item</th> </tr> <tr> <td>1</td> <td> [Security Approvals not required when scans removed in MR](https://gitlab.com/gitlab-org/gitlab/-/issues/37239 "Security Approvals not required when scans removed in MR") </td> </tr> <tr> <td>2</td> <td> [Security Gate: When both merge conflicts and a security approvals are blocking the MR](https://gitlab.com/gitlab-org/gitlab/-/issues/38025 "Security Gate: When both merge conflicts and a security approvals are blocking the MR") </td> </tr> <tr> <td>3</td> <td> [:art: Design: Clarify the state of security approvals while the pipeline is still running](https://gitlab.com/gitlab-org/gitlab/-/issues/370117 "🎨 Design: Clarify the state of security approvals while the pipeline is still running") </td> </tr> <tr> <td>4</td> <td> [:art: Design Follow-up: Investigate validation of required approvals to avoid dead-end-rules](https://gitlab.com/gitlab-org/gitlab/-/issues/352591 "🎨 Design Follow-up: Investigate validation of required approvals to avoid dead-end-rules") </td> </tr> <tr> <td>5</td> <td> [:art: Design: Allow users to prioritise security approval as first things in MR which needs to be checked](https://gitlab.com/gitlab-org/gitlab/-/issues/371325 "🎨 Design: Allow users to prioritise security approval as first things in MR which needs to be checked") </td> </tr> <tr> <td>6</td> <td> <div> <div> <div> [Required approval triggered by scan result policy has a confusing name ](https://gitlab.com/gitlab-org/gitlab/-/issues/384582 "Required approval triggered by scan result policy has a confusing name")https://gitlab.com/gitlab-org/gitlab/-/issues/384582 </div> </div> </div></td> </tr> </table>