Problem/Motivation
This module implements HOOK_entity_access(), which takes precedence over the ContentEntityType's access handler implementation:
* @ContentEntityType(
* [...]
* "access" = "Drupal\precima_serviceportal\PrecimaCustomerAccessControlHandler",
[]...
This is implemented in:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
// Invoke hook_entity_access() and hook_ENTITY_TYPE_access(). Hook results
// take precedence over overridden implementations of
// EntityAccessControlHandler::checkAccess(). Entities that have checks that
// need to be done before the hook is invoked should do so by overriding
// this method.
// We grant access to the entity if both of these conditions are met:
// - No modules say to deny access.
// - At least one module says to grant access.
Hopefully we can improve the situation based on:
// Also execute the default access check except when the access result is
// already forbidden, as in that case, it can not be anything else.
Also https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... points out:
Be careful when writing generalized access checks shared between routing and entity checks: routing uses the andIf() operator. So returning an isNeutral() does not determine entity access at all but it always ends up denying access while routing.
This is a major issue, as if this module returns access denied, the checkAccess() implementation of the Entity access handler isn't called at all and even privileged users like site builders, with their access defined in these classes have no access on view / edit / delete / ... and it's REALLY hard to find this reason!
If we can't fix this by design, we should perhaps at least document this in the UI, where the "deny" behavior can be selected. Sadly the Drupal core fallback seems to be to allow access, if not explicitly denied?
Still, it might make sense to prefer "neutral"?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes