User mapping - Handle memberships

After careful discussion and consideration, the decision was made on how to import members into the new user contribution mapping. And in this issue, we will implement what was decided.

  • Users who have not accepted the reassignment will only become members after the reassignment process.
  • Users who have accepted the reassignment in subsequent imports will automatically become members if they are also members of the source group/project.
  • Users should only be added as members if they are also members in the source instance.
  • Users' access level follows the same existing rules.

Product key points

To prevent confusion and limit user capabilities, placeholders should not be displayed in the 'members' tab or included in an API call for group/project members. In the future, we may revisit this decision if group owners find it useful to modify which access level a user will get after the reassignment.

Proposed backend solutions

Click to read proposal that was not selected

So far, there are two proposed solutions that have pros and cons

1. Import placeholder users as a member

In this solution, we will import placeholder users as members but hide them from API endpoints and UI.

One advantage of this solution is that we don't need to change the reassignment process that was implemented. Therefore, granting a member access to the reassigned user would simply require changing the placeholder user_id with the reassigned user_id.

The downside is that we will have to modify all the features that might be affected by this. For instance, we'll need to update the API endpoints and UI to exclude placeholder users. Additionally, we need to ensure that these users are not counted as billable users in .com.

Another advantage is that if it's decided that showing placeholder users as members is useful, we won't have to make many changes.

2. Create a separate table to store source user member data

In this solution, we will create a slim copy of the member's table. During the import, we will store in the table the access level source users have on each imported group or project. Then, we will extend the reassign process to read the information contained in the table and create a membership for the reassigned user.

The advantage of this solution is that we will not mess up with any membership feature, therefore we will not have to update API endpoints or UI.

The downside is that we will have a different reassign process to handle members.

Edited by Luke Duncalfe