## Background Global search for users as we move to the Cells architecture will need to change. Today on GitLab.com, global user search has no restrictions. This is also true for Users Autocomplete - all users are searched and returned. Some teams at GitLab use Global Users search for internal processes and automation. It's possible that automation may need to change after this work is complete ## Problem to solve ### From [cells 1.0 proposal](https://docs.gitlab.com/ee/architecture/blueprints/cells/iterations/cells-1.0.html#proposal) > The Organization is private, and cannot be made public Groups and projects can be made private, but not public Data indexed into Elasticsearch has all group, project, and project feature permissions deduplicated so any queries for data belonging to a group or project would be appropriately gated and secured. > Users cannot join or interact with other Organizations **Global** search and autocomplete allow searching for all users across the cell. There is no concept of organization within the indexed data at this time. _Note:_ group and project level user search would have the appropriate group/project permissions applied ### From the Cells AMA I learned users have expressed interest in having autocomplete only return users in their groups/projects (outside of the scope of this work). So this change could be beneficial for GitLab.com and SM ## Proposal * Global Search for users scope will stay as-is. Global search direction for Cells 2.0 will be addressed in https://gitlab.com/groups/gitlab-org/-/epics/12893. Since user's are currently global and not directly tied to any entity, global search can work as it does today with some minor differences: * Global search will be Cell-wide. * Users on the primary cell will not be able to search for users on a non-primary cell * Users on a non-primary cell will not be able to search for users on the primary cell * Command palette Users autocomplete will change to always be limited by groups and projects with which the searcher has access. No difference for instance admins. * Only covers the command palette, not any user mentions from issues, merge requests, or comments {width=50%} * Command palette autocomplete already applies user specific limits for the person doing the searches (frequently visited projects or groups and recent issues, merge requests, and epics). So adding that filtering for users makes sense in this area <!-- Please add a label for the type of feature as per https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification -->