Creating two relationships breaks access

This pushed trivial MR fixes the issue for me.

Like so.

Ah, i see, the testUnsupportedOperation test is still red. Know how to fix this, but this needs a thorough code comment. Freaky 3-state semantics again...

Here's the correct fix with comments.

I have a view, which isn't returning any results, and seems like it is matching the issue described here as I have two relationships (Group, and Group content user). However, I do not get a resolution with the patch. When logged in as a user, on the page with the view, (/admin/group here), I don't get any results, when logged in as an admin, and in the view editor, if I add the user ID as the contextual filter argument, I do get results. The only filter I have is "Group relationship: Group relationship type". This did previously work in Group 2.2, but breaks on upgrading to 2.3.

I also tried dropping an xdebug breakpoint on the lines the patch added, and I don't see stopping on those lines at all. I haven't narrowed down if the view is actually getting results out of the query, or if they are being stripped some other way. That's a task for the morning.

So immediately after posting my last comment, I saw that there was a new 2.3.1 release, and a release note to re-run the update hook → . I did so, and it seems to be working now with the patch.

To elaborate on my colleague @bburg's comments, we've confirmed that our issue was actually due to a bug specific to 2.3.0; further upgrading to 2.3.1 fixes it. The patch here doesn't seem to be related, nor does the database update hook (which, rather than needing to be re-run, just needs a manual fix to the module schema version so the upgrade path to 3.3.0 executes).

The actual issue appears to be this item from the release note:

... fixes a permissions bug when group_support_revisions was enabled.

Sorry for the confusion!

Thx for elaborating. To clarify:
- This is abolut "single" access for a page manager page.
- It is not related at all to any views "list" access.

Experiencing the same issue, and wondering at the same time why this seems not to happen frequently for other sites. Are most sites only using one relationship on an entity?

> Are most sites only using one relationship on an entity?

Yes, i suppose.

And: Nice to have you on board here! Did you review or test my approach?

I took a second look for verification and it seems my problem is somewhere else and is probably unrelated to this. I'm not having more than one group content plugin involved for one particular entity, which seems to be in your case (plugin IDs "group_contract__seller:default", "group_contract__buyer:default")?

As nodes usually have one plugin ID in use on a group type, for example "group_node:article" this issue may only show up when dealing with multiple plugins. So even when there are multiple roles defined in one group type, still only one plugin ID is in use.

If the query access logic acts like "if one handler allows access, then access is granted" then yes the loop in group_entity_access needs to be adjusted so that is behaves the same. I took a look into your MR and it might work, just a bit hard to read. Maybe a test that verifies the result between query and runtime access when having multiple plugins involved can make this clear.