- Issue created by @Anybody
- 🇩🇪Germany Anybody Porta Westfalica
Okay this is really crazy!
If simply returning
return AccessResult::forbidden();
in
_entity_access_by_reference_field_user_has_access()
and using "Entity" as views display (rendered media entity) - the entities are still shown, while the rest of the page like all menus is hidden xDSo HOOK_access definitely is not enough!
If doing the same with Views "Field" display, the entities with no access to are hidden, but views outputs an empty div. So this seems to be post-processed, not in the view!
- 🇩🇪Germany Anybody Porta Westfalica
Confirmed by this sentence in the docs:
Note that this hook is not called for listings (e.g., from entity queries and Views). For nodes, see Node access rights for a full explanation. For other entity types, see hook_query_TAG_alter().
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...
- 🇩🇪Germany Anybody Porta Westfalica
After reading a bit more about
hook_query_TAG_alter()
andhook_entity_access()
implementations and limitations, I'm really pessimistic we can solve this soon. =/So I'l listing the helpful sources and options / workarounds I found for now:
1. Starting with: hook_entity_access() which we use to alter access. It documents:
Note that this hook is not called for listings (e.g., from entity queries and Views). For nodes, see Node access rights for a full explanation. For other entity types, see hook_query_TAG_alter().
(https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...)
2. hook_query_TAG_alter() as you can see is SQL-based. Our logic is executed at runtime and I can't see a good way to solve this by altering an SQL query.
3. One way to come around this, would be to implement an advanced postprocess access check in views, for cases where this is relevant.
I'm wondering if there isn't already an existing module for this, as we can't be the first ones running into this?!
So I found these helpful resources as starting point:- https://www.drupal.org/project/veoa → (similar but for routes / arguments)
- https://api.drupal.org/api/drupal/core%21modules%21views%21views.api.php...
- https://drupal.stackexchange.com/questions/207430/how-to-check-for-entit...
4. Entity API provides improvements in [#3002038], but it feels incorrect to hook into these from this permission module and hard to interact with other modules managing access for the entity type. See CR: https://www.drupal.org/node/3002038 →
A helpful blog entry: https://gorannikolovski.com/blog/query-level-filtering-custom-entities-d...5. Finally this needs to be solved in core, but the issue is already 13 years old: ✨ Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() Needs work and far from being solved! :/
- Status changed to Postponed
over 1 year ago 2:14pm 8 May 2023 - 🇩🇪Germany Anybody Porta Westfalica
As a hacky workaround I now created: https://www.drupal.org/project/views_entity_access_check → which can be used until there's a solution in core!
So let's postpone this on the core issue: ✨ Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() Needs work