>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3609288. --> Reported by: [mandclu](https://www.drupal.org/user/52136) Related to !28 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Core automatically tags every Storage entity query with storage_access when accessCheck(TRUE) is used (Drupal\Core\Entity\Query\Sql\Query::execute() adds {entity_type_id}_access for any entity type), and StorageViewsData (via core's EntityViewsData) declares the same storage_access tag as the base table's "access query tag". Both are standard, dependency-free entry points Drupal core provides for exactly this purpose &mdash; but nothing in the Storage module currently implements hook_query_storage_access_alter() to act on that tag.</p> <p>As a result:</p> <ul> <li>\Drupal::entityTypeManager()-&gt;getStorage('storage')-&gt;getQuery()-&gt;accessCheck(TRUE)-&gt;execute() returns entities the current user cannot actually view, even though $entity-&gt;access('view') correctly denies them via StorageAccessControlHandler.</li> <li>The Views field/filter defined in StorageViewsData for storage_access has the help text "Filter for data by view access. Not necessary if you are using storage as your base table," implying automatic filtering &mdash; but no such filtering happens, and the referenced filter plugin id (storage_access) doesn't correspond to any actual plugin class, so adding it in the Views UI produces a broken handler.</li> </ul> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ul> <li>Create a storage entity of any bundle, owned by user A.</li> <li>As user B (not the owner, without a relevant "any"/"administer" permission), run:</li> </ul> <pre>\Drupal::entityTypeManager()-&gt;getStorage('storage')<br>&nbsp; -&gt;getQuery()<br>&nbsp; -&gt;condition('id', $entity-&gt;id())<br>&nbsp; -&gt;accessCheck(TRUE)<br>&nbsp; -&gt;execute();</pre><ul> <li>The entity ID is returned, even though $entity-&gt;access('view') for user B returns FALSE.</li> <li> </ul> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Add a core-only hook_query_storage_access_alter() implementation (no third-party dependency &mdash; same pattern node module uses for hook_query_node_access_alter() / tag node_access) that translates StorageAccessControlHandler::checkAccess()'s 'view'-operation logic into query conditions: for each bundle, OR together status = 1 + "view published (bundle) storage entities", status = 0 + "view unpublished (bundle) storage entities", and status = 0 + owner match + "view own unpublished (bundle) storage entities", short-circuiting entirely for administer storage entities. Detect the base table the same way NodeDatabaseHooks::queryNodeAccessAlter() does (via $query-&gt;getTables() / a base_table metadata fallback), since Views may alias storage_field_data.</p> <p>Once the tag is handled, remove the non-functional storage_access filter definition in StorageViewsData (or the "not necessary if..." help text becomes literally true and the explicit filter can simply be dropped for views on the storage base table).</p> <p>Out of scope: this only covers the module's own baseline published/permission rules. Sites layering custom hook_entity_access() logic on specific bundles (e.g. owner/shared-list restrictions) would still need their own hook_query_storage_access_alter() to get that enforced at the query level &mdash; the same way node access modules must implement hook_node_grants() to participate in core's grants system.</p>