<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve When user is presented with a `Merge` button that is disabled or is presented in "danger red" there are no text near the button to explain why. ### Further details Causes of the problem to solve: * Some error handling is not built into the MR widget so can appear elsewhere in the MR * Gaps in error handling because the API drives the logic for button enable/disabled, while the FE handles the UX of the widget * Mix of FE/BE code for enabling/disabling the `Merge` button is disconnected from the FE code that provides the messaging about the state of the button. ### User experience goal The user should see inside the MR widget clear explanations of what prevents the ability to merge the MR. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * Any user with access to merge a merge request ### Proposal For a disabled or danger-red `Merge` button, provide a list of requirements inside the MR widget to explain conditions relevant to the state of the button. This issue is dependent on https://gitlab.com/gitlab-org/gitlab/-/issues/231335 to consolidate the business logic to determines an MR's error state based on all parameters. The output would be an API message for the correct state of the `Merge` button and a key for building appropriate messages in this issue. ### Design considerations Rough example for illustration only:  These requirements could be collapsible, using Static Application Security Testing (SAST)'s [widget](https://docs.gitlab.com/ee/user/application_security/sast/index.html) as a model. Messaging options: * Only show the requirements that failed * Show the full list of requirements and show a green checkmark for passed and a red X for failed; this gives greater awareness of passed/failed requirements but could be unnecessary details. ### Permissions and Security We will to have access to the project settings in the MR. This is a bit different than what we do right now. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing Unit-test: We would need to test each scenario where the button is disabled or enabled and make sure the corresponding message is rendered. Having this approach also have this advantage that we could test all scenarios where the button should be disabled. If we ever found a new scenario, we could add it in the code and quickly add a test for it. Integration tests: If the logic is tested at the unit test level for each scenario, integration might be needed to validate one case of enabled and one of disabled. I would like to get a QA Engineer opinion on this. ### What does success look like, and how can we measure that? Improved user experience with better explanation of why the `Merge` button is disabled, resulting in reduction of support tickets being logged relating to the disabled MR button. ### Is this a cross-stage feature? This probably affect both Verify and Create group and might require collaboration.