- Issue created by @freelock
I'm working on a city website that uses Group 3.x for department groups, to control edit access to pages "owned" by each department. This is working fine. However, there are certain specific pages that they want to give individual editing access to particular users.
I added a user entityreference field so they can link particular users to the node to grant them edit access, and used ECA to make it work. This works fine if the node is not in a group -- however, when it's in a group, the Group Access takes over and forbids access (if the user is not a member of the group).
The specific place this happens is in \Drupal\group\Plugin\Group\RelationHandlerDefault\AccessControl::entityAccess() -- there's a comment saying:
// If we did not allow access, we need to explicitly forbid access to avoid
// other modules from granting access where Group promised the entity would
// be inaccessible.
... and this is what makes the permissions fail.
I tested commenting out line 193, which sets $result to AccessResult::forbidden(), and this actually solves the problem on this particular site -- group permissions and this ECA are the only permissions editors have that gives them update access at all, so returning a neutral result here gives exactly the right behavior.
So... the question is, what is the best way to address this? Is this line no longer needed with the new Access Policy API? Or should we be implementing something using an access policy?
I spent hours debugging, and did not find anywhere that I could alter a permissions check. I could override this plugin and wrap this method or copy its contents without the forbidden result, but that's the only way I'm seeing to handle this scenario.
If I wanted to replicate my ECA approach in group permissions, how would I go about it? Or is there some way to use the Access Policy API/Flexible Permissions to create a policy that does what we're looking to do, without this method overriding it?
Active
3.2
Code