Access checking must be explicitly set on entity queries

Sorry have never done a patch before so not sure if that merge request was to correct way, didn't see a way to add the patch file any other way. But found the option now, here's quick patch to remove the entity query access check error.

Adding `accessCheck(TRUE)` is correctly re-implementing what is happening now. Looking at the code I think this should actually be `accessCheck(FALSE)`? Because I'm wondering if this does'nt want to avoid duplicates even if the user doesn't have access to it?

This patch, one way or the other, however is needed for D10.

Tested #5 and it fixes the issue, also it is the correct solution IMO:

1. for UniqueReferenceFieldValidator access should not be checked (see #4)
2. fixes another case where accessCheck is not set on the query in GroupPermissionsController::getRevisionIds() (where we should check the access)

I ran into this today and can confirm that the patch from #5 is fixing this. I also think that haven accessCheck(FALSE) is the correct behavior. The way it is now, permissions can not be saved for a group under Drupal 10.1+, which is after all the whole point of this module. :-)

It would be great if you could tag a new release for this. It would be even better if this could be ported to the 1.x branch as well. The concerned class looks the same, so the fix can be applied to both branches without modifications.

The same problem exists in Group Permissions 1.0. Did saomebody already make a patch for 1.0.x?

Reroll of #5 🐛 Access checking must be explicitly set on entity queries RTBC for Group permissons 1.0.0-alpha10. #5 applied quite clean against that release, except for a

Hunk #1 succeeded at 467 (offset -13 lines).

I also tested unchecking some outsider permissions in a group instance. Works OK!

I will introduce today a new release with this fix

Thank you all for your contribution

@LOBsTerr I wonder why we have different access check in v1.0 and v2.0... I believe that both should have same access check like the one in #5. No?

Automatically closed - issue fixed for 2 weeks with no activity.