<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, 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. --> ### 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 <!-- 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)." --> In https://gitlab.com/gitlab-org/gitlab/-/issues/213364, we introduced the Chain of Custody report to include for only Merge Commits. We soon [observed](https://gitlab.com/gitlab-org/gitlab/-/issues/235619#note_420657363) a need to expand this for all commits, as we build features such as filters and search functionalities on top of it. This has also been noted as an action item in the list of [Iteration 2](https://gitlab.com/gitlab-org/gitlab/-/issues/238218). ### Intended users [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#cameron-compliance-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/ --> A user should be able to find any commit that was pushed to a project that belongs in a group. Only one layer of depth Group ⇢ Project to maintain performant queries. ### 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 query in the [csv export service](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/merge_commits/export_csv_service.rb#L25) to query for all commits in a group - Looks like we can use the existing finder method to do this: `app/finders/merge_requests_finder.rb:88` - Update to resultant CSV attributes [here](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/merge_commits/export_csv_service.rb#L41) (for e.g. `merge_commit_sha` may not be applicable for all commits) - Update buttons in the UI <details><summary>Screenshots</summary> | Before | After | | ------ | ------ | |  |  | </details> ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> Since we are querying for all commits in a group, we may need to account for: - Records been truncated due to the 15 MB limit - Query performance ### Permissions and Security Available to Group owners and instance administrators ### Documentation Updates to [Chain of Custody report documentation](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/#chain-of-custody-report)