<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> When organizations use GitLab they often utilize change control systems such as JIRA, ServiceNOW, or others to comply with their change management policy. These change control systems articulate the business case and integrate with other systems to determine if a change is approved, compliant, and acceptable to merge into a production environment. Currently, there's no way for organizations to formally associate a GitLab MR (change) with these change control systems (JIRA, SNOW, etc) to provide a clear, documented chain of custody for the change that occurred. ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> An `administrator` or `group owner` input a specific commimt SHA into a [chain of custody](https://gitlab.com/gitlab-org/gitlab/-/issues/213364) download prompt and receive a CSV report in the same format, but which shows the MR, pipeline, author, approver, etc for that specific commit SHA. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Update the [chain of custody report](https://gitlab.com/gitlab-org/gitlab/-/issues/213364) to filter the criteria to show only data points related to the specific commit SHA provided by a user. 1. An `admin` or `group owner` clicks on the `export` button and sees a prompt 1. Their options could be: `[List of all merge requests]` or `[ Search Commit SHA]` 1. Using the second option, they input `1a2bc3` to find a commit sha report 1. They receive the same report as we've built in https://gitlab.com/gitlab-org/gitlab/-/issues/213364, but it would show _only_ data related to the specific commit SHA |Empty State|Error|Long hash| |---|---|---| |||| ### Implementation outline gitlab~3412464 - `2` https://gitlab.com/gitlab-org/gitlab/-/issues/267629 1. Change the `List all merge commits` button to a [button with dropdown](https://design.gitlab.com/components/dropdowns/#button-combinations) with the new input form. 1. On input done, check if the hash is valid with a simple regular expression. 1. On export click, submit the commit hash to the `mergeCommitsCsvExportPath`. gitlab~2492649 - `3` https://gitlab.com/gitlab-org/gitlab/-/issues/267628 1. Update `MergeCommitReportsController` to accept an optional commit hash paramater. 1. Check if the merge commit exists, if it does not then flash an error message. 1. Update `MergeRequestsFinder` to find by a commit hash (`merge_commit_sha || squash_commit_sha || diff_head_sha`). ### Milestone Goals - [x] `13.4` Reach gitlab~11111313