Search API Group Access

Search API Group Access filters Search API results by Group access. A search returns only the items the searching account may view through Group, and the filter runs inside the search backend, before ranking, so result counts, facets and paging all agree with what the account sees.

Why it is needed

On a site that uses Group 3, a Views listing of nodes hides content from groups the visitor may not see. Group enforces access by altering SQL queries: entity queries that check access, and views built on the SQL query plugin. A Search API view uses its own query plugin and sends the search to the backend, so Group never sees it, and the same visitor searching the same site gets content from every group.

The Content access processor that ships with Search API does not close that gap. It indexes node grants, and Group 3 does not use node grants, so on a site where Group is the only access module it indexes "everyone may view everything". Checking access on the results after the search runs is not enough either: the backend has already picked the top results for the whole site, so an account that belongs to few groups gets fewer results than it asked for, or the worst ones.

What it does

• Adds a Group access processor. Indexing stores, for each item, the group relationships that decide who may view it, plus its owner and its published status.
• At search time it reads the account's group permissions and memberships and keeps exactly the items Group would let that account view, in parity with Group's own entity query access check for the "view" operation. The test suite proves it by running both for a matrix of accounts.
• Membership, role and permission changes apply on the next search, with no reindexing. Adding, moving or deleting a group relationship queues the affected items for reindexing.
• Comments can take on the group access of the entity they are attached to, and two events let any other item do the same.
• A Filter searches by group access setting lets a site index first and start filtering once the index is complete.

Requirements

• Drupal 10.3 or 11
• Group 3.3 or later
• Search API 1.39 or later, with a backend that supports condition groups and IN and NOT IN on multi-valued string fields. The tests run on the database backend, and the module was also checked on AI Search with Qdrant.

Usage

Enable the Group access processor on the index and reindex. On an AI Search index, also set the three access fields to Filterable attributes; the status report flags an index where they are not. The README covers the query options, the Qdrant payload indexes and the extension events.

Known limitation

An item that belongs to two groups can be refused although Group allows it: when the account is a member of the first group, is refused there, and may view the item as an outsider of the second. The module accepts this false negative rather than risk a false positive. Groups themselves are not covered.