I have a fulltext filter on a Search API Solr view with a Rendered HTML Output field on the index. Because anonymous users can't see content, the rendered item needs to be as seen by a particular role (call it subscriber) so I've set that in the settings for the index field. I noticed certain searches weren't returning the expected results; the phrase being searched for was visible on the node when logged in as a user with that role, but was missing in the content in solr.
Digging into it I found that the words being searched for were terms and the reason they weren't in the indexed content was due to a permission check not granting access for a 'view label' operation. It boiled down to the $account->hasPermission('access content') && $entity->isPublished() condition in \Drupal\taxonomy\TermAccessControlHandler::checkAccess(). Because the subscriber role inherits the permission to access content from the authenticated role, that role itself doesn't have the 'access content' permission and therefore that check was coming out neutral, meaning the field was not included in the output.
A user wouldn't have solely the subscriber role in reality so I had assumed the authenticated role would be given automatically.
Whether or not it's technically a bug I'm not sure (and there is a very easy workaround), but I think it's unexpected and at least there should be some text to highlight the need to also select the authenticated role.
The workaround is to just also select the authenticated user role on the field.
- Set authenticated users to have the 'access content' permission
- Create a node with a term field
- Display the term field value on the node view
- Add a rendered item field to the index, and set the user role as a custom role
- Index the content and check content in solr (or alternate implementation)
- The term will be missing from the rendered output
If a non-locked role is set in the field then also add the authenticated user role. Patch to follow.
Needs review.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 3266715-6--rendered_item_always_add_auth_role.patch | 1.42 KB | drunken monkey |
Comments
Comment #2
kimberleycgmComment #3
kimberleycgmComment #4
kimberleycgmComment #5
strykaizerI just encountered the same issue, where our content is behind a paywall (which is checked using user permission).
Patch from #2 fixes the issue, thanks!!
Comment #6
drunken monkeyThanks a lot for reporting this issue. Makes a lot of sense, I agree. I think it’s also safe to say that this is a bug and (hopefully) no-one will rely on the current behavior.
I just have a few code style suggestions – please see, test and review the attached patch revision and I’ll commit it.
Also spotted #3270324: Rendered item processor stores roles as associative array in config while working on this. Very strange.
Comment #7
kimberleycgmThanks for reviewing! I've tested and reviewed the new patch and it all looks good to me. Also tested the other so will update that issue too.
Comment #9
drunken monkeyGreat to hear, thanks a lot for testing and reviewing!
Committed. Thanks again!