Redesign the implementation of "Invite Members" search
Currently, "Invite Members" modal uses /api/v4/users GitLab REST API endpoint for searching users that are eligible for being added to group/project members.
Business requirements regarding who can be added to group/project members are subject to change, examples https://gitlab.com/gitlab-org/gitlab/-/issues/333625, #417300 (closed). Currently, applying new business requirements to "Invite Members" search is problematic, could lead to breaking changes, bad API and implementation decisions since we use the REST API endpoint, examples: !66167 (merged), !63565 (merged), !126059 (merged).
This MR introduces internal endpoints and makes "Invite Members" modal use them instead of /api/v4/users. This will
- improve maintenance of "Invite Members" search
- ease applying new business requirements to the search
- prevent breaking changes
- unblock the solution for https://gitlab.com/gitlab-org/gitlab/-/issues/424505
- allow us to eliminate bad API and implementation decisions we've made
- simplify frontend code by extracting the business logic(example: link) from frontend code to those endpoints. Meaning we won't need to change frontend code anymore when applying new business requirements to the search.
See #460261 (closed) for more details.
References
Screenshots or screen recordings
How to set up and validate locally
-
Feature.enable(:new_implementation_of_invite_members_search). - Test search form for https://docs.gitlab.com/user/project/members/#add-users-to-a-project and https://docs.gitlab.com/user/group/#add-users-to-a-group.
- Enable SSO enforcement for your group and test the search form. It should only return users related to your group. See the screenshot in the "Screenshots or screen recordings" section.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.