Add a "Content access" processor for "Multiple types" indexes

You are right, both of these don't exist yet. Unfortunately, I also don't have the time to implement this in the foreseeable future, since my free contrib time is spent mostly on the D8 port, and maybe bug fixes in D7.

The good news, however, is that this should be pretty easy to implement since D8 already has that processor, so we'd just have to back-port this and combine it with the code of the D7 "Node access" processor (for the actual access logic, functions used, etc.). If someone posts a patch and could test it thorougly (maybe even write a test for it), I'd certainly review and commit it. However, since access checks are of course something pretty delicate, I'd like to be extra-sure here to implement this correctly, so tests (and multiple testers/reviewers) would really be good.

Here's a patch which makes both the node status and node access filters available to the Multiple Types index.

I've taken the same approach as the bundle filter: the supportsIndex() and the alterItems() methods both need to do a little extra work to first check they're working with nodes. I've moved the helper method isMultiEntityIndex() from SearchApiAlterBundleFilter to the base class SearchApiAbstractAlterCallback, so the two node filters can use it too.

Thanks, that looks pretty good already!
However, I fear the trickiest part is still missing: search_api_search_api_query_alter() and _search_api_query_add_node_access() need to be re-written to also deal properly with those indexes. Possibly, looking at the D8 version of this code could help you there, since there we also have different entity types in the same index (though the API for it is somewhat different).

Also, it seems you didn't adapt SearchApiAlterNodeAccess::configurationFormSubmit() either, which has to take care that all the required fields are indexed.

Has there been any movement on this issue? While the ability to index both nodes and terms is a great thing, it can't be giving the users access to view the unpublished content in the results listing. That is a huge issue.

I wrote the patch for a client's D7 project I was working on at the time, which I'm no longer on -- I'm afraid I won't have any more time to work on this particular issue, sorry.

Has there been any movement on this issue? While the ability to index both nodes and terms is a great thing, it can't be giving the users access to view the unpublished content in the results listing. That is a huge issue.

You can just add a filter to exclude published content, if that's your only access restriction.

Rerolled this for latest dev.

I think this is most of the way there - the _search_api_query_add_node_access function has been rewritten to be more like the D8 version. Solr seems to be choking on the nested filters that this introduced, so it's not 100% working yet. I haven't tested it with other backends. Not sure if the issue is in search_api or search_api_solr, still looking into it.

It works with search_api_db so it looks like this is some issue with search_api_solr. Marking this as "Needs Review".

Finally tracked down this issue. The patch from https://www.drupal.org/node/2902963#comment-12225434 will need to be applied for anyone using search_api with this patch in combination with search_api_solr.

Looks pretty good, thanks!
Attached are some revisions, which should also fix the test fail and make this work for comments, too.
Please test/review!

I applied this patch to 7.x-1.22 and resulted in the following error

Recoverable fatal error: Argument 2 passed to _search_api_query_add_node_access() must implement interface SearchApiQueryInterface, instance of stdClass given, called in /var/www/docroot/sites/all/modules/contrib/search_api/search_api.module on line 2079 and defined in _search_api_query_add_node_access() (line 2112 of /var/www/docroot/sites/all/modules/contrib/search_api/search_api.module).

Rolling a new patch.

-function _search_api_query_add_node_access($account, SearchApiQueryInterface $query, $type = 'node') {
+function _search_api_query_add_node_access($index, $account, SearchApiQueryInterface $query) {

became

-function _search_api_query_add_node_access($account, SearchApiQueryInterface $query, $type = 'node') {
+function _search_api_query_add_node_access($account, SearchApiQueryInterface $query) {

I just removed the $index, since that gets pulled in through a call to getIndex().

Ah, yes, forgot to update that call, apparently. Thanks for catching that!
However, in the future, please include an interdiff when posting patches!
Otherwise, this looks good now, I'd say. So: committed.
Thanks again for your work, everyone!

Please revert this. See #2958201: Only admin can access search page after search_api upgrade to 1.23

Reverted.
On closer look, that patch really had a number of problems. Should have reviewed this much more carefully – sorry about that!

The first change that should happen is that it doesn't really make any sense to have two separate data alterations for comments and nodes, if they're gonna use more or less the same code anyways. (Didn't make much sense before, but makes even less now.)
So, I'd drop the comment access plugin and integrate its functionality into node access. (This will of course also need an update hook.) Side benefit: The check whether the plugin is present gets a lot simpler.

Then, why does SearchApiAlterNodeStatus::getNode() not just use the same code as the "Node access" plugin? (No trait possible in D7, unfortunately, so copying the code.) See attached revision.

Now, for the main problems:

1. +++ b/search_api.module
   @@ -2094,59 +2109,121 @@ function search_api_search_api_query_alter(SearchApiQueryInterface $query) {
   +  $status_field = NULL;
   

   $status_field stays NULL for single-type indexes.

2. +++ b/search_api.module
   @@ -2094,59 +2109,121 @@ function search_api_search_api_query_alter(SearchApiQueryInterface $query) {
   +  elseif ($index->item_type === 'node') {
   

   This should check for getEntityType(), not $item_type.

3. +++ b/search_api.module
   @@ -2094,59 +2109,121 @@ function search_api_search_api_query_alter(SearchApiQueryInterface $query) {
   +    $status_field = $entity_type . ':status';
   

   This only works for multi-type indexes, for the others the field is just status – this one doesn't exist, leading to an exception at search time.

4. +++ b/search_api.module
   @@ -2094,59 +2109,121 @@ function search_api_search_api_query_alter(SearchApiQueryInterface $query) {
   +      $author_field = $entity_type . ':author';
   

   Same here.

Also, seems like SearchApiAlterNodeAccess::configurationFormSubmit() would also need an overhaul to enable to correct fields on enabling the data alteration, even for comment and multi-type indexes.

You can just add a filter to exclude published content, if that's your only access restriction.

Just came across this issue of unpublished nodes appearing in a multiple types index. I don't understand this from comment #7? I assume it's meant to say "exclude unpublished nodes" but what is "just add a filter" in reference to?

Using Search API Pages atm, I guess we could switch to use views and filter that way - is that what you meant?

Adding a related issue which I chose to work on for some reason. Not sure how well aligned it is with @drunken monkey's latest comment in this issue now that I see that comment.