Views entity_access check

TL;DR:

Adds "view" ($value->_entity->access('view')) access check on each views row pre-render.

Try this module, if you're using a custom access restriction module, but entities keep showing up in views, which the users can't access and should not be shown. Only enable on views where needed, until #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() is sovled. Read details below.

Why and when is this helpful?

Drupal's Entity Access API provides a great toolkit to define access for entities. Still hook_entity_access() has a weak point, which leads to confusion and hard DX:

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().

(FYI: Nodes instead still uses the additional GRANT system we know since Drupal 6. So they're even more special.)

As it's not possible to provide an SQL-based solution for all permission modules (which calculate permissions at runtime with complex logic in hook_entity_access for example), these modules won't work as expected in Drupal Views (and EntityQueries, which should be solved in code).
Typically in those cases you'll see entities listed in views, which the user can not access ("Access Denied") and in worst case it means information disclosure.

There's a core issue to find better ways: #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() but until this is solved, this module provides a hacky workaround implementing HOOK_views_pre_render and checking "view" access on the _entity property.

foreach ($view->result as $key => $value) {
  if (!empty($value->_entity) && !$value->_entity->access('view')) {
    unset($view->result[$key]);
  }
}

Affected access / permission modules

We've written the module for our modules:

• entity_access_by_reference_field: #3358544: Need to implement hook_query_TAG_alter per parent entity type to work with views correctly?
• entity_access_by_role_field: #3358543: Need to implement hook_query_TAG_alter per parent entity type to work with views correctly?

but also know about issues in similar modules:

• Access by Reference: #3239917: Support views by implementing hook_node_grants and hook_node_access_records instead of hook_node_access

which can't implement hook_query_TAG_alter() and handle non-node entities.

Notes & Downsides:

This should be seen as quickfix with the following downsides:

• Access checking each entity in the view decreases performance and thereby should only be used in views where it's needed
• Whenever possible hook_query_TAG_alter() should be implemented in access modules
• This may have further downsides, so test carefully, especially in combination with caching and complex access restrictions.

So this module will propably never have a stable 1.0.0 release, but hopefully core will provide a nice DX solution instead, so this can be removed.

After reading all this, please help us to fix #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() together!

Installation & configuration

1. Identify the views where you have the described issues
2. Install the module
3. Go to the settings page: /admin/config/system/views-entity-access-check and select only the views to run the additional access check on
4. Check if your issue is gone and test carefully

Also relevant

• #2953566: Allow entities to specify a "collection permission"

Similar modules

• Views Entity Operation Access: Provides an access plugin for the view to hide it entirely based on an entity permission

Supporting this module

Support DROWL's ♥ FOSS work on this module on OpenCollective!

Drupal and this module are FOSS. However, it takes dedicated people to develop and maintain. And they need YOU to give back!

We're committed to building and maintaining Drupal modules that benefit the entire community.

Supporting us on OpenCollective helps us continue to improve, innovate and contribute to Drupal's future. Every pledge makes a difference!

If this module has helped you, we would be very grateful for your donation to support its further development and maintenance.

Support our FOSS development ♥️

You can also speed up the development of features or bugfixes you'd love to see, by sponsoring and giving back!

Sponsor a feature or bugfix 🚀

Let's make Drupal even better, together!

Development proudly sponsored by German Drupal Friends & Companies:

webks: websolutions kept simple (https://www.webks.de)
and
DROWL: Drupalbasierte Lösungen aus Ostwestfalen-Lippe (OWL), Germany (https://www.drowl.de)