User mapping - Handle group transfers to another parent group

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

GitLab allows you to transfer a group, subgroup, or project to a different group. The current design of the improved user mapping does not handle the transfer appropriately, which may lead to unintended side effects if the transfer feature is used.

The biggest issue is that the placeholder user and the source user records are scoped to the top-level group. When a transfer occurs, the top-level group is modified, breaking the fundamental rules and assumptions of the current design.

Examples of problematic use cases:

Use case 1

1. The group owner migrates source GroupA and GroupB into TopLevelGroup1.
2. Group owner transforms GroupA into a new top-level namespace
3. Group owner reassigns placeholder user contributions to users

The Group owner of GroupA won't be able to reassign contributions assigned to placeholder users.

If a reassignment is performed via TopLevelGroup1, contributions assigned to GroupA will also be reassigned. In other words, TopLevelGroup1 could still alter the user assigned to contributions in GroupA.

Use case 2

1. The group owner migrates the source GroupA into a TopLevelGroup1.
2. Group owner transforms GroupA into a new top-level namespace
3. Group owner deletes TopLevelGroup1

We have not yet implemented the function to delete placeholder users. In theory, deleting TopLevelGroup1 should also delete the placeholder users because the top-level namespace that owns the placeholder user would be deleted. However, we cannot delete the placeholder users because GroupA may have contributions assigned to them.

Use case 2 is no longer a problem, as the worker responsible for deleting placeholder users checks all tables if the user is not referenced.

Use case 3

1. The group owner transfers TopLevelGroup1 into TopLevelGroup2 transforming TopLevelGroup1 into a subgroup.

The group owner may lose the ability to reassign contributions.

Proposed solution

When a group or project is transferred to a different top-level group, contributions associated with them can no longer be reassigned to real users. Therefore, any desirable reassignment would have to happen before the transfer. Reassignment would work as usual for groups and projects that weren't transferred.

An alert on the transfer page will prompt group owners to reassign placeholder users before transferring.

The reassign process won't consider all "transferred" contributions, which means they would stay associated with placeholder users. Because of that, these placeholder users must be kept in the database and will count to the top-level space placeholder limit.

In terms of backend changes, we will have to perform the following changes:

1. Add the columns group_id, project_id to the import_source_user_placeholder_references table.
2. Populate the group_id, project_id during migration
3. When a group or project is transferred to a different top-level namespace, delete all references in the import_source_user_placeholder_references table that belong to the transferred group or project.

To illustrate the change, consider the following 'import_source_user_placeholder_references' table. It contains placeholder user references that belong to the top-level namespace with ID 1, and these references belong to groups 2 and 3, as well as projects 4 and 5.

id	source_user_id	namespace_id	group_id	project_id
1	100	1	2
2	100	1	3
3	100	1		4
4	100	1		5

In case group 3 and project 5 are moved to top-level group 6, the respective references will be deleted, the reference table will appear as:

id	source_user_id	namespace_id	group_id	project_id
1	100	1	2
3	100	1		4

Similary, we should also delete the import_placeholder_memberships records for the transferred group and projects.