fidzu : cms

A member of two departments asks the intranet's assistant what the company has on SMTP. The vector database ranks the whole intranet, hands back the ten closest passages, and Drupal then throws away the ones she may not open. She gets whatever is left, fewer than she asked for and not the best she could have had. On the search page next door, the same thing shows up as a result count above a list shorter than the page, and a pager that runs past the last result she can open.

That is what happens on a site built with Group 3 as soon as the search goes through Search API. Group enforces access by altering SQL queries, so Views listings of nodes respect it. A Search API search goes to its backend, where Group never sees it. The Content access processor that ships with Search API indexes node grants, and Group 3 uses none.

Search API Group Access closes that gap where it opens, inside the search backend. It is free software under GPL-2.0-or-later, and 1.0.0, released on 8 November, is its first stable release. It plugs into Search API and Group, and works on any backend that supports condition groups and IN filters: the database backend, and AI Search on a vector database such as Qdrant.

What you can build with it

• A search page on an intranet or extranet whose result count, facets and pager agree with what each member sees, because the backend ranks and counts only that.
• An AI assistant that answers from your content and retrieves only from the groups the person belongs to, so asking for ten passages returns ten they can open.
• A new member who finds the group's documents on their very next search. Memberships, roles and permissions are read when the search runs, so changing them reindexes nothing.
• Comments found by whoever may see the entity they are attached to, and reindexed when that entity changes groups, owner or status.
• Paragraphs, or any other entity Group does not relate, that take on the access of their host through one event subscriber.
• A large index rolled out with no gap in service: index the access values with the filter off while searches keep working, then switch the filter on without reindexing.

The same answer as Group, or no answer

The rule the module is built to is parity with 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, and it runs on Drupal 10 and 11.

Where it cannot be exact, it errs towards hiding. An item that has not been indexed with the processor yet is returned to nobody. There is one known case where Group would show an item and the search does not, in an item that belongs to two groups when the insider role grants less than the outsider role, and the module accepts that false negative rather than risk a false positive. Groups themselves are not covered, and neither are operations other than "view".

Caching gets the same care. Turning the processor on or off saves the index's views again, so a results cache never serves one member's results to the next.

Where it came from

We built it for our own intranet, where an assistant answers questions from about 270,000 items stored in Qdrant through AI Search, and every one of its searches goes through the filter. The person who sees least of the intranet asks for ten passages and gets ten, all of them ones they may open.

Getting there taught the module two things it now does by itself. Values meant to be matched exactly are hashed to plain hexadecimal, because AI Search runs every text attribute through an HTML to Markdown converter that escaped the underscores in them. And the status report flags an AI Search index whose access fields are not set as filterable attributes, where every search would otherwise come back empty. On Qdrant, give those fields payload indexes: on an index of 190,000 points, a filtered search took 100 to 210 ms without them and 2 to 16 ms with them.

Get it

composer require drupal/search_api_group_access
drush en search_api_group_access

Then check Group access on your index's Processors tab and reindex. It requires Drupal 10.3 or 11, Group 3.3 or later and Search API 1.39 or later. Stable releases are covered by Drupal's security advisory policy.

The README covers the rollout on a large index, AI Search and Qdrant, and the events. If you also need entity reference fields to offer only the content of the group being edited, Group Entity Reference Filter does that. And if your site shares content out by group in a way the module does not cover yet, tell us in the issue queue.