just wondering if set per-node and then unset per-node settings...
if {acl} and {acl_node} (and probably {acl_user}) should still be filled or cleared, cause when unset per-node settings, the default settings will repopulate as node_access is rebuilt. but having those abandoned entries still in those tables, makes it seem like content_access realm is empty (thats what Devel's Node Access will report which is confusing as the 'all' realm is handled by content_access too? and isnt empty)...
here are some screenshots attached when uncheck per-node and when manually delete those acl entries.
see how in 1st pic, 'content access' is empty but 'content access: all' isnt, seems confusing.
The content_access table still has those settings saved in case user wants to turn settings back on. so i was thinking maybe the acl tables should be cleared?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | debugging output.txt | 4.07 KB | armyofda12mnkeys |
| 2 after delete acl table rows manually.jpg | 44.68 KB | armyofda12mnkeys | |
| 1 per node setting unchecked - abandoned rows.jpg | 68.47 KB | armyofda12mnkeys |
Comments
Comment #1
salvisI agree that CA should remove the ACL entries that don't grant any access.
Also, I wonder what that empty entry is. Apparently, CA supplies an empty-array grant, i.e. a grant record that doesn't even have the realm key set. It should not supply this record.
@armyofda12mnkeys: where did gid=4 go?
Comment #2
armyofda12mnkeys commented> where did gid=4 go?
oh sorry didnt clarify on that... In my default content-type settings, gid=4 doesnt have access (but per-node settings it did). So when uncheck per-node setting, it repopulated the default settings.
sidenote: i think i read somewhere drupal's 'all' realm, when applied to nid=0 and gid=0, applies that setting to all nodes (versus 1 node specifically as in my case). i couldnt find a reference to that. is that true?
Just wondering how should i interpret the realm "content access: all", does that mean really mean content_access module is giving access to the realm called 'all' indirectly?
>Apparently, CA supplies an empty-array grant, i.e. a grant record that doesn't even have the realm key set. It should not supply this record.
Is there anything i can do to help debug this? i dont think its a database entry, code might accidentally be making it maybe?
Comment #3
armyofda12mnkeys commentedbtw: the empty array grant, im not sure if this helps, but here is some info i outputted about that node (should be settings from 1st pic, so per-node is on, and 0,4,5,6 are gid's for content_access ).
this is some output i outputted in devel block as its getting grants to display.
Comment #4
salvisIndeed, CA's hook_node_access_records() returns those empty grant records. They are ignored (as DNA points out), i.e. not inserted into the {node_access} table, but CA shouldn't return them in the first place.
Re "content access: all": indeed, CA pretends to be core and returns an 'all' grant, as you're showing in the attachment of #3. See #239139: Do not hijack the 'all' realm. The presence of that 'all' grant used to be ultra-confusing until I started exposing the source...
IMO, it's presumptuous and completely unnecessary for CA to hijack the 'all' realm, but fago apparently doesn't see it that way...
To answer your question: core inserts a single 0/all/0/100 grant into {node_access} when no node access modules are enabled, and this ensures that db_rewrite_sql() will work correctly.
Comment #5
armyofda12mnkeys commentedcurious why its getting empty grants. what exactly causes it in hook_node_access_records()... an entry in node_access(i didnt think since all and content_access were only ones i saw in there and they are returned)? or not sure?
>unnecessary for CA to hijack the 'all' realm
gotcha. yeh i was thinking same thing, it would be less confusing if a content_access_all realm was in there.
>core inserts a single 0/all/0/100 grant into {node_access} when no node access modules are enabled, and this ensures that db_rewrite_sql() will work correctly.
Gotcha thanks for clarification.
Comment #6
fagoComment #7
gisle