## Summary The notes advanced search query currently uses legacy `project_id` authorization for issue confidentiality filtering. This should be migrated to use the modern `traversal_ids`-based confidential filters available in the `Elastic::Filters` class. ## Current Implementation In `ee/lib/elastic/latest/note_class_proxy.rb`, the `confidentiality_filter` method (lines 68-145) implements custom confidentiality logic that relies on: - Direct `project_id` terms queries for authorization - Manual construction of boolean filters for confidential issues - Separate handling for issue and non-issue confidentiality **Key problematic code:** ```ruby filter[:bool][:should] << { bool: { must: [ # ... confidential issue checks ... { bool: { _name: context.name(:user, :issue_author, :issue_assignee, :project_membership), should: [ { term: { "issue.author_id" => current_user.id } }, { term: { "issue.assignee_id" => current_user.id } }, { terms: { project_id: project_ids } } # ← Legacy project_id authorization ] } } ] } } ``` ## Proposed Solution Migrate to use the standardized confidentiality filters in `ee/lib/search/elastic/filters/confidentiality_filters.rb`, which provides: - **Traversal IDs support**: Uses `traversal_ids` for efficient ancestry-based authorization - **Unified filtering**: Handles both project and group-level confidentiality - **Better performance**: Optimized queries with proper trie-based traversal ID filtering - **Consistent authorization**: Aligns with other search entities (issues, merge requests, etc.) The `ConfidentialityFilters` module provides: - `by_project_confidentiality` - Project-level confidentiality with traversal_ids - `by_group_level_confidentiality` - Group-level confidentiality - `by_combined_confidentiality` - Combined project and group filtering ## Benefits 1. **Performance**: Traversal IDs enable more efficient group-level searches 2. **Consistency**: Aligns notes search with other entity types 3. **Maintainability**: Removes duplicate confidentiality logic 4. **Scalability**: Better support for deeply nested group hierarchies ## Implementation Notes The refactor should: 1. Replace the custom `confidentiality_filter` method in `NoteClassProxy` 2. Use `Search::Elastic::Filters.by_combined_confidentiality` or `by_project_confidentiality` 3. Ensure proper handling of note-specific fields (`issue.confidential`, `issue.author_id`, `issue.assignee_id`) 4. Maintain backward compatibility with existing search behavior 5. Add appropriate tests for group-level note searches with confidential issues