Customizable Default Scope in Search
Proposal
Implement admin-configurable or user-configurable default search scope for GitLab Search, allowing administrators to set whether searches default to Code, Projects, Issues, etc., rather than the current hardcoded default to Projects.
Implementation location could be set in the Admin settings at admin/application_settings/search#js-global-search-settings
Proposal
Start with an instance level application setting that works for all instance types (CE and EE) and all search types (basic, advanced and exact code search). This setting can be used by SM and Dedicated instances and also tested on GitLab.com
Technical notes
automatic scope routing
The backend routes users to certain scopes (depending on where they are in the application when a search is conducted). The backend checks which controller the request is being generated from and for a few controllers chooses the related scope. This code would need to be changed to ensure that any setting is chosen instead of these.
current default scope
The default scope is set by the backend in a few places:
I think we can set the default scope here but know that if a user doesn't have the right permissions to view that scope, another scope must be chosen. Need to be careful about the logic
scope order in ui
The order of scopes in the UI is determined within the Search::Navigation class. Do not recommend changing this in the first iteration. The work should focus on setting the default scope but keep the order consistent/as is.
Admin UI settings considerations
Propose to create a scopes class as a single source of truth to understand which scopes are available on an instance. The admin UI should show a default scope option that isn't available (for example, epics on a CE instance).
Questions
- how to handle scopes that are turned off for global search? should they be allowed to be default scopes? GitLab.com is an example, if
codeis set to the default but also not allowed in global searches how will that work?