Explain MERGE button state through better messaging in the MR widget

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.

Release notes

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)
• 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 #231335 (closed) 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 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

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.