When nodes have multiple taxonomy, the node can be falsly visible in listings

Thanks for patch and the report.

In your latest patch the $orGroup variable is undefined. Also it cannot be applied on the latest dev-version, because the AccessStorage service class code changed. Please be so kind and modify your patch, so that it can be applied.

Can you provide a test for this? If you are not able to create a test for this: can you describe a scenario for reproducing the issue?

I have been following this issue, as I have the same problem, and was looking forward to the patch being part of the latest update (1.33). Sadly it wasn’t, but should really be part of the next one. Thank you harings_rob for providing the patch in the first place! :) I’d help out with it, but I have no coding skills.

Step-by-step to reproduce the issue using two taxonomy vocabularies (use default values unless otherwise specified):
Turn on “Single Term Restriction” in PbT Configuration screen
Create a taxonomy vocabulary
Create a term in this vocabulary and give it a user permission
Create a term in the Tags vocabulary with no permissions set
Create a content type
-Do not include a menu link
Add two taxonomy fields to the new content type
-One for the Tags taxonomy
-One for the taxonomy just created
Create a node using this new content type
-Assign one of the created terms to each of the taxonomy fields
Create a View
-View Settings: show “content” of type “all” tagged with “[term you created in Tags vocabulary]“
-Create a page with Display Settings: “unformatted list” of “full posts”
-Create a menu link on the “main navigation” menu
Log out
Log back in as a user who does not have permission to view created node
Click on menu link for the created View
The forbidden node should be visible in the view (showing it’s full content)
Click on the node
-page now displays “Access denied”

I have discovered that the same issue occurs with a single vocabulary with multiple terms.

To reproduce with only a single vocabulary:
Same general step-by-step as above, except...
Create a second term in the Tags vocabulary and give it a user permission
Create a content type with just one taxonomy field
-Use the Tags vocabulary with unlimited number of values
Create a node with the two created vocabulary terms
Create a View, using the term with no permissions, for View settings.

I hope this helps!

I get the following error having applied the patch to 8.x-1.33

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: Syntax error or access violation: 1463 Non-grouping field 'inlist' is used in HAVING clause: SELECT n.nid AS nid FROM {node} n WHERE ((n.nid NOT IN (select CASE WHEN ti.tid IN (select tid from {permissions_by_term_role}) THEN ti.nid END as inlist FROM {taxonomy_index} ti HAVING inlist))) AND ((n.nid NOT IN (select CASE WHEN ti.tid IN (select tid from {permissions_by_term_user}) THEN ti.nid END as inlist FROM {taxonomy_index} ti HAVING inlist))); Array ( ) in Drupal\permissions_by_term\Service\AccessStorage->getNidsWithNoTidRestriction() (line 663 of /.../modules/contrib/permissions_by_term/src/Service/AccessStorage.php).

Thanks for reporting and the patch! I will review the patch soon and run some tests.

Please check the latest release, which ensures that PbT is not handling any nodes, which are not related to taxonomy term permissions: https://www.drupal.org/project/permissions_by_term/releases/8.x-1.35. There might be problems solved, which are part of this issue.

Fixed query for retrieving all nodes with no term restriction. Also fixed kernel event listener for single node access, if an node has no related terms. In my manual tests I could not reproduce the issue anymore, after I have implemented the fix (before I could reproduce the issue - thanks for the steps). I will try to prepare an automated test, before this goes into release. You can see the edits in the following commit (own Git branch):

http://cgit.drupalcode.org/permissions_by_term/commit/?h=2908742&id=69b7...

And no worries: you will get the credits via my final Git commit. :)

I have added the test and pushed the changes into the dev branch. http://cgit.drupalcode.org/permissions_by_term/commit/?id=bdba065cb8935e...

I am closing this issue. Please feel free to re-open, if you have any further objections.

have you checked my git commit? i think i have solved that.

that's fixed. gets into next release. thanks everyone.

Have you tested the latest dev branch with the mentioned Git commit? I have been fixing your first failing patch with the wrong sql statement.

@harings_rob: I have implemented your changes and tested it. I could not reproduce it with MySQL version 5.6.35. However the Drupal.org testbot reported the failing test with an newer MySQL version. Thanks again for your patch!

Please re-open this issue, if you have any objections.