Skip to content

Redesign the implementation of "Invite Members" search

Resolving this issue should unblock the solution for https://gitlab.com/gitlab-org/gitlab/-/issues/424505.

Why? was initially described in !147732 (closed).

When we limited search result on Invite Members to users with group's SAML or SCIM identity for groups with SSO enforcement is enabled, it caused https://gitlab.com/gitlab-org/gitlab/-/issues/424505. We need to unblock the solution to resolve that issue.

The policy which users can and cannot be added to members, as per the group settings, is subject to change along with developing GitLab application. The existing implementation is not designed for its extension. Any extension of the existing implementation we have done is a hack and could lead to bugs and even breaking change since we use API... Let me rationale below.

Since introducing Service Accounts, we changed policy to allow service account users to be added to members if SSO enforcement is enabled for the group. We allowed that on the backend side. However, to allow users to do so from UI, we had to change the search implementation. We needed to do this change quickly to allow customers that use SSO enforcement to use service accounts. But there was no any possible way to do this change correctly so we did a hack: We changed User.limit_to_saml_provider(saml_provider_id) method and /api/v4/users?saml_provider_id=ID API endpoint to return group's service accounts. This method name and API endpoint with saml_provider_id emphasize that it should return only users with the group's SAML identity, however it now returns the group's service accounts users which has no relation to SAML at all. We should change that since it could lead to bugs in the future.

Then we discovered https://gitlab.com/gitlab-org/gitlab/-/issues/424505. To keep the existing UX for Invite Members and to unblock the solution to resolve that issue we are about to add new API endpoints !134570 (merged) and !144796 (closed). At first glance they looked promising, but:

  • Since the policy which users can and cannot be added to members, as per the group settings, is subject to change along with developing GitLab application, those endpoints are subject to change too. It breaks promises that any endpoint changes under /api/v4/ should follow REST API deprecations and removals process if there is no security reason for that. I know we mentioned that those endpoints are for internal purposes in the docs, but It won't stop some users to start using it. And in case if any of this endpoint is changed in few month or years, we will break those customers workflows and it will lead to an incident because any change to an API endpoint is a breaking change.
  • Those endpoints looked promising and useful for users and for evolving, however after the following change !141040 (comment 1773138463), we made those endpoint available only when SSO enforcement is enabled. As a user, I find it very confusing that I cannot use neither GET /groups/:id/users nor GET /projects/:id/users endpoints for my groups that do not have SSO enforcement enabled. Those endpoints has no value for group that do not use SSO enforcement despite those endpoints names do not emphasize that they are supposed to work for SSO enforced groups only. I don't see any reason why those endpoints should only be allowed for use when SSO enforcement is enabled, at least we should change that.

Implementation plan

Edited by Bogdan Denkovych