Add the Planner role to the remaining search visibility specs

Ravi Kumarrequested to merge
538212-planner-search-visibility-specs into master

What does this MR do and why?

Adds the Planner role to the search visibility specs that did not have it yet, at project level. This is a test-only change. There is no application code change.

Some tables already had Planner rows: merge requests, notes on issues and merge requests, commits, notes on commits, milestones, and Advanced Search blobs. These use permission_table_for_planner_feature_access, permission_table_for_planner_notes_feature_access, permission_table_for_planner_confidential_issue_access, permission_table_for_planner_internal_note_access, permission_table_for_repository_access, and permission_table_for_milestone_access.

This MR covers the rest:

  • Adds Planner rows to permission_table_for_guest_feature_access. Project-level issues, work items, wikis, and notes on snippets visibility specs use it, across global, group, and project search.
  • Adds Planner rows to permission_table_for_project_access. The projects scope uses it.
  • Adds Planner rows to permission_table_for_project_snippet_access. Project snippets in ee/spec/services/ee/search/snippet_service_spec.rb use it.
  • Switches the Zoekt blob search contexts (global, group, and project *_blobs_visibility_spec.rb) to permission_table_for_repository_access. Their Advanced Search contexts already use this table. Before, Zoekt used permission_table_for_guest_feature_access_and_non_private_project_only.

Planner has at least Guest access to these features. Each Planner row therefore has the same expected count as the Guest row.

Why the non-private table has no Planner rows

permission_table_for_guest_feature_access_and_non_private_project_only is left without Planner rows on purpose.

In a private project with a private repository, BlobPolicy lets a Planner read code, so the expected count is 1. Project.filter_by_feature_visibility(:repository, user) in spec/models/project_spec.rb returns nothing for a Planner in the same case. One table cannot satisfy both, so that table stays as it is.

This MR does not change that mismatch. It is tracked in #632187 (closed) and fixed in !259718 (merged), which also adds Planner rows to this table.

Not in scope:

  • Group-level visibility specs. The issue handles these separately.
  • Personal snippets. They have no project role.
  • Non-search tables: permission_table_for_reporter_feature_access, permission_table_for_notes_feature_access, and permission_table_for_reporter_issue_access.

References

Screenshots or screen recordings

Not applicable.

How to set up and validate locally

No manual steps. This change only touches specs. The changed visibility specs run in CI.

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.

🤖 Generated with Claude Code

Edited by Ravi Kumar

Merge request reports