Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
QueryAccessEvent currently is used as such:
// Allow other modules to modify the conditions before they are used.
$event = new QueryAccessEvent($conditions, $operation, $account);
$this->eventDispatcher->dispatch('entity.query_access.' . $this->entityType->id(), $event);
I'd like it to support generic listeners too, much like the entire entity system does for everything else:
- hook_entity_insert vs hook_ENTITY_TYPE_insert
- hook_entity_update vs hook_ENTITY_TYPE_update
- etc.
Some modules may need to alter queries depending on how they are configured and can therefore not know beforehand which entity types they want to listen to. It would be cool if we could fire a generic event first and make sure we can read the entity type ID from QueryAccessEvent.
// Allow other modules to modify the conditions before they are used.
$event = new QueryAccessEvent($conditions, $operation, $account, this->entityType->id());
$this->eventDispatcher->dispatch('entity.query_access, $event);
$this->eventDispatcher->dispatch('entity.query_access.' . $this->entityType->id(), $event);
Comment | File | Size | Author |
---|---|---|---|
#12 | entity-3134363-12.patch | 6.09 KB | kristiaanvandeneynde |
| |||
#12 | interdiff-9-12.txt | 1.35 KB | kristiaanvandeneynde |
Comments
Comment #2
kristiaanvandeneyndeMade it so the entity type ID can be NULL for now for BC reasons, but it does already call a trigger_error.
Comment #3
kristiaanvandeneyndeObviously you can change this part as you see fit.
Comment #5
kristiaanvandeneyndeLet's make sure the new test method only handles the thing it focuses on and does not interfere with other tests.
Comment #7
kristiaanvandeneyndeNow if we could refrain from breaking the test we just wrote...
Comment #9
kristiaanvandeneyndeFixed the tests leaking into one another.
Comment #10
Berdir8.1.1 isn't really a version and depending on how you interpret it, it would introduce a change in either a minor or a patch version.
I'd actually be OK with just requiring it. See #2960643-27: Cannot load entity by uuid after rename for a similar case. The new method is a string return and code will expect it to be there, so it would break there.
Same as in the core issue, I'd argue the constructor here isn't an API and code outside of entity module isn't meant to reuse it.
Comment #11
kristiaanvandeneyndeOkay fine by me. I use the constructor directly in Group, but that's really an edge case where the base access handler both does too little in one area and way too much in another for the special use case that is Group. 99% of all modules will want to use the base query access handler.
I'll adjust the patch right away.
Comment #12
kristiaanvandeneyndeComment #13
BerdirOops, crosspost:
I'm also OK with keeping it, but then we need to figure out something useful for the deprecation message. At least we now know that next major version is going to be 2.0.0 ( a year ago, we didn't know if it would be 8.x-2.x or 9.x-1.x), so I'm also OK if we put that in there. Also, I think the new guidelines would be "entity:2.0.0" then, similar to how core now uses "drupal:9.0.0".
Comment #14
kristiaanvandeneyndeI think very few modules use this system already and those that do (including Commerce) use the stock query access handler as a base. So Group is the only module I know of that builds the event itself.
If you want to err on the safe side, go with patch from #9 and adjust the "Entity API 8.1.1" to say "entity:2.0.0". If you think the risk is indeed minimal, go with #12.
Comment #16
BerdirOk, #9 with the changed message it is. Unlike the core issue, the new argument is for the new generic case, so someone doing something with the existing event (class) might still work. And it doesn't hurt. Updated the version.