Use traversal_id auth in advanced user search
What does this MR do and why?
This MR moves to using a custom namespace ancestry filter for User scope search in advanced search.
It also fixes a subtle bug when searching globally with autocomplete (from Search or go to...). The prefix search was using group.id when it should have been using group.elastic_namespace_ancestry (think 9970 vs 9970-)
This change is introduced behind a derisk FF: search_advanced_users_new_auth_filter
Ai summary
This code change introduces a new feature flag called search_advanced_users_new_auth_filter that improves how user searches work in GitLab's advanced search functionality.
The main improvement is replacing the old authorization filtering logic with a new, more optimized approach that uses "traversal IDs" to determine which users a person can see based on their access permissions to projects and groups. Instead of running multiple separate filters, the new code consolidates this into a single, more efficient filter.
The change includes comprehensive test updates to verify both the new behavior (when the feature flag is enabled) and the old behavior (when it's disabled), ensuring backward compatibility. The feature flag is initially set to "disabled" so it can be safely rolled out and tested without affecting existing functionality.
This optimization should make user searches faster and more reliable, especially for users who have access to many projects and groups, by reducing the complexity of the database queries needed to determine search permissions.
References
- Related to #491217 (closed)
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
- setup elasticsearch in GDK
- enable advanced search in Admin settings + index the instance
- this will require some setup
Group Structure:
================
Group 24
└─ Group 35
└─ Group 27
└─ Project 4
Group 99 (unrelated)
User Memberships (namespace_ancestry_ids):
==========================================
User A: [“24-“] (member of Group 24)
User B: [“24-“, “24-35-“] (member of Group 24 and 35)
User C: [“24-“, “24-35-“, “24-35-27-“] (member of Group 24, 35, and 27)
User D: [“24-35-27-p4-“] (member of Project 4)
User E: [“24-35-“] (member of Group 35)
User F: [“24-35-27-“] (member of Group 27)
User G: [“99-“] (member of Group 99)Searching in Group 27 (ancestry: “24-35-27-“):
Query filters for:
- prefix: “24-35-27-” (Group 27 and all descendants)
- terms: [“24-“, “24-35-“] (ancestor groups)
Results:
--------
✓ User A (has “24-” in terms)
✓ User B (has “24-” and “24-35-” in terms)
✓ User C (has “24-35-27-” matches prefix)
✓ User E (has “24-35-” in terms)
✓ User F (has “24-35-27-” matches prefix)Searching in Project 4 (ancestry: “24-35-27-p4-“):
Query filters for:
- terms: [“24-“, “24-35-“, “24-35-27-”, “24-35-27-p4-“] (ancestor groups)
Results:
--------
✓ User A (has “24-” in terms)
✓ User B (has “24-” and “24-35-” in terms)
✓ User C (has “24-35-27-” in terms)
✓ User D (has “24-35-27-p4-“ in terms
✓ User E (has “24-35-” in terms)
✓ User F (has “24-35-27-” in terms)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.