Replicate shared membership structure on direct transfer import of top-level group
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
This issue was created from this discussion !148220 (comment 1869843637).
About
A recent change has been made to Direct Transfer so that if a user already has access to a project being transferred by virtue of a pre-existing shared or inherited shared membership the existing membership is recognized and new direct memberships in the project are not created.
To leverage existing memberships a top-level group on the source must be imported into an existing group with appropriate memberships on the target, which does not preserve the group path and requires the membership structure to be duplicated before attempting to import the dependent groups/projects.
It is therefore not possible to use a single direct transfer operation to perform a 1:1 transfer of a top-level group and it's sub-groups and projects and retain the original full group/project membership structure. This is not what might be expected by customers wanting to utilize direct transfer to carry out migrations between, for example gitlab.com and a self-manager GitLab instance.
This issue proposes direct transfer be enhanced to replicate the group/project membership hierarchy in full, within the bounds of the top-level group being transferred.
For example, at present if the source group has the following structure:
Group-A -> Subgroup-A1 -> members(User1, User2)
-> Subgroup-A2 -> Project-A3 -> members(Group-A->Subgroup-A1)a direct transfer of Group-A will result in:
Group-A -> Subgroup-A1 -> members(User1, User2)
-> Subgroup-A2 -> Project-A3 -> members(User1, User2)This is because direct transfer only checks whether the users already have access to Project-A3 when it is created on the target - it doesn't ensure newly created shared group Subgroup-A1 is made a member of Project-A3.