I am really not sure if this is a bug, or rather something that was not caught before, or this is like this for a reason, but I rather report what I found. I guess I am going to have to find a workaround for my needs: I am working on a rule action that create a pdf out of a node using the print module. I need this action to be run on node creation and for anonymous users. I also use content_access for some particular node access scheme. I was consistently getting access denied when the rule was being executed as anonymous and debugging everything I found something.
There's some validation on the print module that relies on node_access($node, 'view) that's arguable whether it has to be there or not, but anyway, I noticed both the hook_entity_insert and hook_node_insert is being executed before any access is grant to the node. Thus, rendering any rule or anything that can happen on hook_xxx_insert that may eventually depend on node_access('view') useless.
I know this is very specific, just wondering why this was made like this and what are the implications of moving it around. I know this have almost cero chances to be considered, but I worth mentioning. I am going to submit a patch to change this and see how the tests bot reacts to it.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | grant_before_insert_hooks-1425974-1.patch | 804 bytes | hanoii |
Comments
Comment #1
hanoiiComment #2
kscheirer#1: grant_before_insert_hooks-1425974-1.patch queued for re-testing.
Comment #3
kscheirerRetesting against latest HEAD since it has been over a year.
Comment #5
mcrittenden commentedHere's an example of a bug in contrib caused by this: https://www.drupal.org/node/2612234
Comment #14
catchThe original use case could be solved by doing the processing in a queue. I can't see a reason to change the order - this has been explicitly done in post save for some time (as well as node indexing), so closing as works as designed.