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. For intranets, extranets and any site whose content is shared out by group.

Features

• 🔒 Access checked by the backend. A Group access processor indexes, for each item, the group relationships that decide who may view it, with its owner and its published status, and adds a condition to every search. The backend ranks and counts only what the account may see, so no result is missing from a page and no count includes a hidden item.
• 🔒 The same answer as Group. For the "view" operation, a search returns an item if and only if an entity query that checks access would, as far as Group decides: outsider, insider and individual permissions, "any" and "own", published and unpublished. The test suite runs both for a matrix of accounts and compares the results.
• ⚡ No reindexing when people change groups. Memberships, roles and permissions are read when the search runs, so a new member finds the group's content on the next search. Adding, changing or deleting a group relationship reindexes only the item it relates, and the items that follow its access.
• ⚡ Cached results per account. The search varies by the account's group permissions, and turning the processor or its filter on or off saves the index's views again, so a results cache such as Search API (tag-based) never serves one account's results to another.
• ⚙️ Comments follow their entity. Group relates entities to groups, not comments. With the processor's comment setting, on by default, a comment is found by those who may view the entity it is attached to, and is reindexed when that entity's groups, owner or status change.
• ⚙️ Index first, filter later. With Filter searches by group access off, the processor indexes the access values and filters nothing, so a large index can be rebuilt while searches keep working, and the filter turned on with no reindexing.
• 🔌 Events for site code. AccessEntityEvent lets any item take on another entity's group access, such as a paragraph its host's, and DependentEntitiesEvent names the items to reindex when that entity changes.
• 📊 AI Search and vector databases. The indexed values pass through AI Search unchanged, and the status report flags an AI Search index whose access fields are not set as filterable attributes, where every search would come back empty.

Quick start

composer require drupal/search_api_group_access
drush en search_api_group_access

1. Go to Configuration > Search and metadata > Search API, edit your index and open its Processors tab.
2. Check Group access, leave Filter searches by group access checked, and save. This marks every item for reindexing.
3. On the index's View tab, click Index now.
4. Search as a group member: the results, and the count above them, hold the member's groups' content and the content in no group, and nothing else.

Good to know

• An item is returned to nobody until it has been indexed with the processor. On a large or slow index, such as one with embeddings, enable the processor with Filter searches by group access off, let the index rebuild, then turn the filter on.
• It works alongside Search API's Content access processor: each adds its own condition, so an item must pass both, as a node passes both core's node access and Group's check in an entity query. On its own, Content access does not see Group 3, which uses no node grants.
• An item in 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; it only arises when the insider role grants less than the outsider role for the same content.
• Groups themselves are not covered: groups indexed with the processor on are never returned by an access-checked search. Only the "view" operation is covered, and only Group 3.
• On AI Search, set the three access fields to Filterable attributes in the index's AI Search field settings, then reindex. On Qdrant, create payload indexes for them: on an index of 190,000 points, a filtered search took 100 to 210 ms without them and 2 to 16 ms with them.

Additional requirements

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

Recommended modules/libraries

• Group Entity Reference Filter: limits the options of an entity reference field to the content of the group the edited entity belongs to.
• AI Search: semantic search on a vector database, filtered by group access with this module.

Community documentation

• README: setup, the rollout on a large index, AI Search and Qdrant, the query options, the events with an example subscriber, and how the index encodes access.

Supporting this module

Developed and maintained by Bloomidea. Bloomidea offers support and custom development for this module.