User Mapping - API Development (GraphQL)

On this issue, we will work on creating the GraphQL endpoints that will be used by the improved user mapping.

Two types of users will interact with the feature: group owners and assigned users.

Initially, group owners will use the User reassignment UI, which will be supported by the GraphQL endpoints created here.

Group owners will be able to list all import source users and reassign a real user to a source user. They can also cancel that reassignment if needed. This endpoint must:

• Only be accessible to group owners.
• Return paginated Import::SourceUser records
• Include a mutation for assigning a real user to an Import::SourceUser
• Include a mutation to revoke the assignment of a user from an Import::SourceUser
• Include a mutation to keep as a placeholder user

Note: These endpoints should only be available when the feature flag improved_user_mapping is enabled.

Questions: Should the email actions also be accessible via these endpoints?

changed milestone to %17.1

added Category:Importers backend devopsmanage groupimport and integrate sectioncore platform typefeature workflowblocked labels

set weight to 3

added to epic &12378 (closed)

mentioned in issue #443555 (closed)

Cross-linking to #443555 (comment 1870429892) and whether the new API support for this feature should be implemented in GraphQL.

@SamWord @jnutt Do you think we should close this issue and implement as GraphQL in #457066 (closed) #443555 (closed)?

@.luke This is #457066 (closed). Were you thinking of a different issue?

@jnutt Sorry, I meant to link to #443555 (closed). I've updated the comment, it should (hopefully) make more sense now.

Thanks! Yes, I think if the current plan is to implement the group owner-facing endpoints only in GraphQL, we can close this issue and clarify the issue body of #443555 (closed).

It might be better to clarify the issue body of #443555 (closed) and update this issue to reflect that we want to implement the group owner actions in GraphQL. It really doesn't matter either way, the comments discussing how to implement this is GraphQL are super helpful and enough to start work on it. I just have a preference for more small issues over one big one with multiple MRs

added ready for next refinement label

mentioned in issue #458765 (closed)

removed weight of 3

set weight to 4

changed weight to 3 from 4

changed the description

changed title from User Mapping - API Development (API endpoints) to User Mapping - API Development (GraphQL)

added workflowready for development label and removed workflowblocked label

removed ready for next refinement label

mentioned in issue gitlab-org/quality/triage-reports#17611 (closed)

mentioned in issue gitlab-org/quality/triage-reports#17714 (closed)

mentioned in issue gitlab-org/manage/general-discussion#17673

added Stretch label

mentioned in issue gitlab-org/quality/triage-reports#17795 (closed)

mentioned in issue gitlab-org/quality/triage-reports#17901 (closed)

mentioned in issue gitlab-org/quality/triage-reports#18066 (closed)

mentioned in issue gitlab-org/quality/triage-reports#18168 (closed)

assigned to @rodrigo.tomonari

added workflowin dev label and removed workflowready for development label

mentioned in issue #466636 (closed)

changed the description

marked this issue as blocking #455912 (closed)

marked this issue as blocking #455902 (closed)

mentioned in epic &12378 (closed)

changed milestone to %17.2

removed Stretch label

added Deliverable milestonep1 labels

mentioned in issue gitlab-org/manage/general-discussion#17674

We should also remember to guard some of the endpoints with the bulk_import_user_mapping feature flag.

@rodrigo.tomonari I've love to be used as a reviewer for this one

@rodrigo.tomonari @.luke I just had a look at the MR and I noticed that both this issue and MR don't have the Notify action (when state is awaiting_approval and admins want to resend the email to the mapped user). Can we add it as it's part of the design? Separate MR is fine too.

@justin_ho, I thought the Notify action would be implemented by #455912 (closed). Do you think we need a separate issue to implement the Notify action?

@rodrigo.tomonari I don't think these are the same. The issue above is about sending the email when admins first reassign a source user. What I am referring to is re-sending that notification manually. You can have a look at the designs (see "Pending approval" state) to see what the UI looks like.

I basically need an endpoint to which the frontend will send a request and get a success / error.

@justin_ho, I see. Totally forgot about the "Notify Again" button.

So, it's missing a NofifyReassign mutation which should resend the email to the user, right?

Yes that's correct. I think it will be fairly straightforward so up to you if you want to split out to separate issue / MR.

@justin_ho, I created a different issue.

So we can close this issue and unblock the following issues.

Setting health status to on track as the milestone has just begun.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to on track

mentioned in issue gitlab-org/quality/triage-reports#18252 (closed)

mentioned in merge request !156687 (merged)

changed the description

mentioned in issue gitlab-org/quality/triage-reports#18360 (closed)

added workflowin review label and removed workflowin dev label

added workflowcomplete label and removed workflowin review label

closed

marked this issue as blocking #469665 (closed)

@rodrigo.tomonari I started work on the frontend to fetch the data from GraphQL and so far it's working pretty good. One very small thing we need to add is allowing users to filter the results into 2 tabs: "Awaiting reassignment" (all pending states) and "Reassigned" (kept as placeholder and complete states). You can have a look at the design. Do you think it can be added as a small MR? (Feel free to create a separate issue if needed)

@justin_ho, I plan to add the filter capabilities as part of User mapping - Add filtering support (#455902 - closed). I have already created a draft MR.

Something worth mentioning is that I did not add a filter as described above. However, the frontend can supply an array of statuses to achieve the desired result. I believe that with this approach, the GraphQL API becomes more flexible, but the downside is that the frontend has to understand the meaning of each state. Is this okay from the frontend perspective?

@rodrigo.tomonari Ah ok I didn't notice that issue, all good then. And yes an array of status is ok as well.