Split up OgAccess::userAccessEntity()

[pfrenssen]

Fixes #672

[pfrenssen]

This is ready but since this is built on top of #671 I will keep this in draft until the other PR is accepted.

[pfrenssen]

Setting back to draft since this needs more work. I am running tests on my "big" project and there is a regression. ::userAccessEntity() was being called from og_entity_access() with an entity operation, both on group content and group entities. It should only do this for group content from now on.

We have currently no full support for entity operation permissions on groups, only for the update operation (through the UPDATE_GROUP_PERMISSION GroupPermission). I will make a followup to add also a delete permission.

[pfrenssen]

Created followup #674 but I had another look and we can still retain the functionality in scope of this, we simply need to check if we are handling a group entity and if this is the case we can translate update to UPDATE_GROUP_PERMISSION and delegate to ::userAccess(). It will be solved in a couple lines and there will not be a regression for now.

I propose to handle the test coverage for this in #674. We don't have the coverage right now and this would be out of scope.

[pfrenssen]

I have added the code which solves the regression and I think this is now complete.

I will keep this in draft until I have finished work on #674 - that issue will complete the entity operations for group entities by adding the delete operation. Most importantly it will also add the necessary test coverage which I think is out of scope for this PR.

I also want to run the extensive test suite on my work project that has discovered this regression.

[pfrenssen]

I am near finishing work on #674. Here is the coverage for the regression on hook_entity_access(): https://github.com/Gizra/og/pull/681/files#diff-103d019edfa64fc25b94e05082e8bba8R332

This is now ready for review.

[pfrenssen]

@MPParsley Thanks for reviewing! I addressed the remark. I will wait for test results to come back green before merging. I can then "unlock" the next PR.

This OgAccess refactoring is coming to an end soon, I have finished work on the final 2 PRs (#681 and #684) and I am now working on integrating them into my project so I can run our extensive test suite.

I can also still as part of this work write the release notes for the next release since this is breaking backwards compatibility. We can still break B/C as long as we're in alpha but I would like to inform our users so that they will know what to expect when updating.

[MPParsley]

Thanks for the update!

I'm mostly worried about the impact on the ongoing PRs for beta blockers (e.g. #231, #242, #570, ...).

[pfrenssen]

The impact is due to having split the entity access check into separate checks for user permissions and entity operations. So existing code that is checking entity operations will need to call the other method now.

Here is an example how this now looks in my project code: (ref. https://github.com/ec-europa/joinup-dev/pull/2184/files#diff-f26d2164853bef0da7d08750148704f5L86)

-    return $this->ogAccess->userAccessEntity('create', $this->createNewAssetRelease($rdf_entity), $account);
+    return $this->ogAccess->userAccessEntityOperation('create', $this->createNewAssetRelease($rdf_entity), $account);

Also if people are implementing hook_og_access_alter() and are altering the results expecting entity operations to be passed in, they will need to use hook_og_access_entity_operations_alter() now. Example: https://github.com/ec-europa/joinup-dev/pull/2184/files#diff-0c9ed0667150da0d6130597e6bb8789bR179