### Problem to solve As described in #19128, an admin account is required to import projects with contributions associated to users. ### Intended users * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### User experience goal User should be able to import projects with contributions associated with current group members. ### Proposal As proposed in https://gitlab.com/gitlab-org/gitlab/-/issues/19128#note_310394703, this would be a MVC version of #19128, whereby **project contributions will be associated if**: - importing into a group namespace (not user namespace) - importing user is an owner/maintainer within (sub)group they are importing into - contributor is a member of the (parent) group a project is imported into **All contributions will be associated with the importing user if any of the above conditions is not met.** This means that contributions **will not be associated** if: - user does not exist on the destination instance - email associated with user listed in project export does not match the *primary* email of any user (NOTE: on the export side, **users needs their email set to public** in order for that email to be exported and used later on during mapping) - user exists but is not a member of the (parent) group ### Further details As evidenced in #19128, this is frequently asked for, particularly for GitLab.com as users are never admins on this instance. Support currently has a workaround for small use cases, but it's very resource intensive, and the demand for this is growing. ### Permissions and Security This should be safe as contribution mapping is scoped to group membership, so would not require admin priviledges. ### Documentation Existing documentation would need to be updated: - project imports: https://docs.gitlab.com/ee/user/project/settings/import_export.html#important-notes - migrating projects: https://docs.gitlab.com/ee/user/project/import/#migrating-from-self-managed-gitlab-to-gitlabcom Side note, [Support process](https://about.gitlab.com/handbook/support/workflows/importing_projects.html) would also need to be updated. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? Support no longer gets requests for these types of imports. ### What is the type of buyer? This currently affects all users interested in preserving associations.