<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=592886) </details> <!--IssueSummary end--> ## Summary Refer to linked issue for detailed background (https://gitlab.com/gitlab-org/gitlab/-/work_items/592310). This issue covers the short term plan described in the linked issue, in relation to file-based imports and the need for an admin token on Gitlab.com to do contribution history mapping. Longer term, file-based imports are being planned for deprecation and will be replaced by Offline Transfer (https://gitlab.com/groups/gitlab-org/-/work_items/8985). ## Current state and problem statement Today, file-based imports into gitlab.com require an instance admin token in order to accurately map users' contribution history between source and destination. The mapping is done automatically as part of the import workflow, unlike other (non file-based) import methods we have which use an interim container in the form of placeholder users (e.g. direct transfer). Due to this, there is an implied security need to ensure that this mapping action is only carried out by privileged accounts on gitlab.com. Without an admin token, contribution history is mapped to the user executing the import, leading to inaccurate contribution mapping. Due to this requirement for an admin token, there are limitations on who can execute a file-based import into gitlab.com as only GitLab team members are eligible to have admin accounts on gitlab.com. This limits our ability to scale PS engagements for imports which need to use file-based migrations, e.g. certain Congregate migrations like ADO -\> GitLab, and all current air-gapped migrations. In addition, the need to create multiple admin accounts for multiple file-based migrations happening at any point in time is not ideal as it leads to a sprawl of privileged accounts for our core service. ## Proposal **Allow top level group Owner role (both user and service accounts) to carry out mapping of contribution history directly on gitlab.com, _only_ if users on destination are Enterprise users.** **Exception path (if not enterprise user or not Group owner) will default to current behavior - contributions will be mapped to the user executing the import.** Notes and considerations: * Provides us with the most effective immediate outcome. * Relatively least amount of effort to implement (to be triaged by the engineering team). * Strikes a balance between security and flexibility. * This doesn't require us to plug the PHU/UCM workflow to file-based imports which will take a considerable amount of effort. * If an organization claims enterprise users, it is fair to say that the TLG owner should have the ability to directly assign contributions to them.