Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter()

After running into the described issue with Views and Custom Entities in combination with custom access modules that determine access based on field values and relations at runtime, I wrote https://www.drupal.org/project/views_entity_access_check → as (more or less hacky) workaround to do an additional access check on each views row: $value->_entity->access('view')

This is surely expensive, but okay as opt-in for simple cases. Eventually I'll create a Core issue for Views to discuss adding something like this as advanced settings. With complex hook_entity_access() conditions on non-node entity types, a solution becomes more and more important, I think.

Happy to receive feedback and improvements in the module's issues. And even happier if we get this fixed in core one day, so this won't be needed anymore! :)

I would expect that with Modern Drupal's caching system we could probably take care of 70% of the performance issues of doing what is proposed in #231

We took the PoC patch in #75 and converted into a module since we needed this functionality.

As such, the overall design is still very similar to the core node access system of records and grants extended to custom content entity types. This is what we needed since we need something that will scale to larger number of entities and where we could easily apply the same kind of logic we are using for our custom OG-based node access records and grants.

Contributions are, of course, welcome (especially tests and review)
https://www.drupal.org/project/raft_entity_access →

Curios about the differences between RAFT Entity Access and Flexible Permissions → .

With regard to 🌱 [Meta, Plan] Pitch-Burgh: Policy based access in core Active is what is proposed in this issue still a good idea? I would rather we don't have multiple access and control systems hanging around. Maybe once 🌱 [Meta, Plan] Pitch-Burgh: Policy based access in core Active is in core the resolution here would be to deprecate the existing node access rights system rather than expand it into entities. Or maybe break node access and entity access into a node sub-module. Having multiple systems that do the same thing is generally bad DX.

If anyone is looking for a solution to this today there is also the Access Policy module → which has implemented many of these concepts. If/When these API changes make it into core I will also integrate those changes into the module.

To learn more about it you can read the documentation → or watch a recent episode of the Talking Drupal podcast where they featured it.

Re #235 and #236 as I explained in the other issue, Flexible Permissions and the work I'm currently doing to get it into core has nothing to do with query access. See #3371246-17: [Meta, Plan] Pitch-Burgh: Policy based access in core →

While implementing a custom content type entity, I looked into access checking related to entity query logic and found this issue. I also created this support request 💬 Does entity query access checking perform any access checking for custom content type entity? Active to confirm my understanding of entity query access checking.

In that support request, I've also proposed a few documentation changes and happy to have these documentation discussions over there. I think be helpful to communicate more clearly for custom content type entity developers.

Changing to the DX special tag defined on Issue tags -- special tags → .

Coming back to this after all these years, I no longer feel like the solution we have in Entity API is sufficient for core. I tried it out with Group and ended up having to copy a bunch of it because of Group's complicated structure.

So what I instead propose is a service collector that gathers the right metadata from either an entity query or a views query (like Entity API and Group do now) and then passes that along to the tagged services for alteration. In a second phase, we could introduce a core tagged service that copies some of the work from Entity API so that people can still define entity type query access handlers that return some of the value objects we saw earlier.

• Phase 1: Service collector, allow modules to alter queries more easily
• Phase 2: Port the entity type handler from Entity API as a tagged service
• Phase 3: Try to provide sane defaults for every entity type in said handler

#240 @kristiaanvandeneynde

This lacks one key feature of entity module approach:
IMHO the entity module approach is the right direction in adding a declarative field condition that can be applied to single-entity AND entity-query access. I think it is NOT expressive enough though.