- π©πͺGermany Anybody Porta Westfalica
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! :)
- πΊπΈUnited States frob US
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
- πΊπΈUnited States pwolanin
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 β - πΊπΈUnited States frob US
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.
- πΊπΈUnited States partdigital
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.
- π§πͺBelgium kristiaanvandeneynde Antwerp, Belgium
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 β
- πΊπΈUnited States jasonawant New Orleans, USA
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.