Direct-transfer placeholder users: list Enterprise users for re-assignment on gitlab.com

added devopsfoundations docs-comments documentation gitlab.com groupimport and integrate typefeature labels

changed milestone to %Backlog

mentioned in issue #503356

Hi @m_frankiewicz, while testing with a customer on .com I've realized they can only search the placeholder user drop-down by name or username. Search by email does not work for non-admin users. This means the Owner re-assigning the users would need to know the exact username (from IdP?) in order to find the correct user.

@pprokic I just saw your message in google docs:

Did a bit more testing and realized one can search the re-assignment users by name, username or email. And if I enter my email in the dropdown I get a unique match. So, although the source email is not provided under the Source column of Placeholders it might after all be ok as long as they can retrieve the IdP email used to provision the user.

I just did some testing myself. For my, search by email for non-admin worked.

Not in Admin mode, if I type full email of the user on destination, the search gives the single correct user:

or

Without full email (still typing) it doesn't work:

Typing name gives lots of results:

Correct destination username works - one result (this we know):

Would it help to show the source user email in the second column?

Hi @m_frankiewicz. Thanks for checking. It seems both of you have the public_email field exposed, which explains why you can search as a non-admin. If you e.g. try to search for me that should not work.

Oh, @pprokic, public email, I see. Coming back to this one.

changed the description

@wortschi I'd like to have this refined before 17.10, but it doesn't need to be in the upcoming Friday refinement issue.

@wortschi adding to ready for next refinement. Could this land in today's refinement issue?

@m_frankiewicz We can add it to the next refinement issue, but I won't open one before next week. There are still items to be refined on the current refinement issue.

@wortschi in the current refinement issue there are 4 not yet refined issues, so this one should still make it below the limit of 6 issues.

@m_frankiewicz No because I have already removed the ready for next refinement label from 3 out of these 4 not yet refined issues. Looking at the list of issues that are marked for the next session in https://gitlab.com/gitlab-org/gitlab/-/issues/?label_name=ready%20for%20next%20refinement - we have 8 open issues (one of them is already being refined in the open issue) so we have 7 open issues at the moment for the next async issue.

We can sync on it next week before opening a new issue.

Let's do it @wortschi. I'd like to know to best ask for refinement so that it gets done in requested timeframe

For sure - we can only refine 3-6 issues per week as per our process. The ready for next refinement should only be applied by the EM - for reference: https://handbook.gitlab.com/handbook/engineering/development/dev/foundations/import-and-integrate/#step-1-identifying-issues-for-refinement - otherwise we'll end up it situations like in the past where to many issues have this label and manual work is needed to clean it up. We can discuss this in our 1:1 to find a process that works for Product as well

changed the description

added gitlab-org#16766 as parent epic

mentioned in issue #455901

mentioned in issue #520988

added ready for next refinement label

mentioned in issue #522916

changed milestone to %17.11

mentioned in issue gitlab-org/foundations/general-discussion#17696

When we search for the users to reassign contributions to, we currently query the users GraphQL field. This supports a groupId argument, which will cause the finder to use Autocomplete::GroupUsersFinder.

But it sounds like enterprise users are a special kind of user within a group, for example in these docs it mentions that you can filter members by enterprise users. In the members controller, enterprise members filtering happens through GroupMembersFinder when passed enterprise: true argument.

So I don't think we can't query enterprise users through the users GraphQL field - it's using a different finder.

There is an existing GraphQL query that uses this finder, group.members, through GroupMembersResolver added in !145331 (merged).

For example this query should return back enterprise members for a group:

{
  group(fullPath: "<group full path>") {
    groupMembers(enterprise: true) {
      nodes {
        id
        user {
          id
          name
        }
      }
    }
  }
}

For me, the query does not actually work locally, but this is because it silently ignores the filter here if my group hasn't been set up to support enterprise users - which it hasn't in my case.

So long as the feature check we make when determining if we should query users is the same one that GroupMembersFinder makes, it should all work.

In this case the frontend would switch between searching users through the existing users GraphQL query that it currently does, or the group.groupMembers query, based on if the group supports enterprise users or not.

It looks like from GroupMembersFinder this can be determined by if group.domain_verification_available? is true.

It would make this work mostly frontend I think, with perhaps the backend needing to supply the boolean property to help the frontend know which GraphQL query to use.

@tachyons-gitlab does the above sound correct to you, specifically that we would check group.domain_verification_available? to decide if we should query enterprise users for the group or not?

@bdenkovych Could you help here as you have more context ?

We only allow filter members in a group by Enterprise badge if it is gitlab.com and the group has at least GitLab Premium subscription - that is the main goal of the group.domain_verification_available? check.

I don't understand the context of the issue, but in case if we need get list of all enterprise users regardless they are members of the group, there is GET /groups/:id/enterprise_users API endpoint that group Owners can use.

Thanks @bdenkovych. The context is when re-assigning (Placeholder) users to contributions on a gitlab.com group, one does not want to search among all users on .com, but rather have a way to filter the list. In case of this issue, the idea is to use the already available group enterprise users list, if possible, to limit human error by allowing the Owner to serch for a user by email instead of username.

GET /groups/:id/enterprise_users API endpoint allows group Owners search enterprise users by their private emails. Related spec: https://gitlab.com/gitlab-org/gitlab/-/blob/f83cba8774b7eca735ebfd74a4021c30e81094f1/ee/spec/requests/api/group_enterprise_users_spec.rb#L178

Thanks for looking into this @.luke. I also noticed that the EE helper for group members includes an attribute can_filter_by_enterprise which includes the domain_verification_available? check. I guess we still need an new attribute that shows if a group has SCIM enabled.

@m_frankiewicz So just to reiterate the requirements of this issue (and correct me if I am wrong). When we have an Owner of a group on gitlab.com, they are at least on GitLab Premium plan, and have SCIM enabled, we should filter by Enterprise users of that group only instead of all users on the instance.

On the frontend, we need to change the query for this scenario (hopefully to the GraphQL query as we are already using this), then make sure all functionality still works as expected.