I have a taxonomy structure like this:
Parent1
-Child1
-Child2
Parent2
-Child3
-Child4
Can i set access via the parent term? So if a role could access Parent1 but not Parent2, they could also access Child1 and Child2 but not Child3 and Child4.
New terms will be added so if the structure became this:
Parent1
-Child1
-Child2
-ChildA
Parent2
-Child3
-Child4
-ChildB
Then I would need the role to be able to access ChildA but not ChildB. Users on my site will be able to create terms so this needs to happen automatically, I cant adjust the access from the module's settings page each time. Can this module do that? Thanks
Comment | File | Size | Author |
---|---|---|---|
#23 | taxonomy_access-inheritance-1673558-23.patch | 24.97 KB | karoop |
| |||
#9 | taxonomy_access-inheritance-1673558-9.patch | 15.11 KB | karoop |
| |||
#8 | taxonomy_access-inheritance-1673558-8.patch | 6.86 KB | karoop |
| |||
#5 | taxonomy_access-inheritance-1673558-5.patch | 6.84 KB | karoop |
|
Comments
Comment #1
jdln CreditAttribution: jdln commentedCould someone confirm if this is possible to do or not? Thanks
Comment #2
spgd01 CreditAttribution: spgd01 commentedThis should be the case but I have not gotten it to work this way. If I want to deny child pages I have to set deny on each page. This is a bug in my opinion. Children should inherit the parent access unless over ridden with allow or deny, ignore should inherit parent but we should not have to create an ignore for every single taxonomy term. This is very laborious.
Comment #3
vegansupreme CreditAttribution: vegansupreme commentedWhat about when someone moves a child term out from under it's parent? If ChildA moved from Parent1 to Parent2, I would expect the permissions to change accordingly. That doesn't seem to be happening either. Is this a separate issue?
Comment #4
davidneedhamClosing duplicate issue #2209657: New Child pages do not inherit taxonomy and referenced a fixed issue for D6 that is this exact issue
Comment #5
karoop CreditAttribution: karoop commentedI managed to add grant inheritance to the module. So far it works for node permissions (tag permissions coming soon).
It works in a very simple way: When setting permissions for a node, it looks for vocabulary terms applied to the node and searches for their ancestors. Then it overwrites the 'ignore' or default permissions for the tag following the tag hierarchy, with the deepest-nested grants taking precedence over higher-level grants.
So, for example, if you have a tag that has a view permission (let's call it 'vt'), all nodes tagged with 'vt' or its children will have the view permission without the need to explicitly state that in the permissions table. You can then add a view deny permission to a child of 'vt' (let's call it 'dt'), and all of the nodes tagged with 'dt' or children of that term will have the view permission denied.
When you save permissions table, nodes tagged with children of the term you edited are marked for permissions update, so updating the parent term also applies all changes to children - of course respecting their explicit settings.
I created the patch with #1266674-10: Support other databases and #2674852: Grants in role permissions table all show as 'Ignore' regardless of current state. applied because my environment is Windows and MSSQL Server.
Comment #6
karoop CreditAttribution: karoop commentedComment #8
karoop CreditAttribution: karoop commentedOops, parse error in patch! This should work.
Comment #9
karoop CreditAttribution: karoop commentedOK, I managed to add inheritance to tag permissions as well. If you apply this, you'll be able to set 'Add tag' and 'View tag' permissions hierarchically. This patch includes the changes in the patch from #2674852: Grants in role permissions table all show as 'Ignore' regardless of current state. because values for tag permissions have been slightly changed, and updating the table generating code fitted very nicely with the changes I made there.
Again, I created a patch in the environment containing changes from #1266674-10: Support other databases because it enables the module to work with my installation, but neither of the patches in this issue contains those changes.
Comment #10
karoop CreditAttribution: karoop commentedThis is hopefully my last addition to this issue and it addresses the problem of deny grants not overriding allow grants. The problem is that if you deny access to one term for one role, but allow in another, the allow will override the deny.
In my opinion, this approach is a lot less flexible than being able to override allow grant, but required a lot more work due to how grants are given in Drupal.
In my patch, I have implemented the
hook_node_access()
that checks which nodes the user can access, and denies access if the user has an explicit deny grant for the term on the node. This led to another problem: Menu links do not use thehook_node_access()
, so they were showing the inaccessible items anyway. To fix that, I have implemented thehook_query_node_access_alter()
which is called when the menu is checking access, and modified the query to only select the nodes available to the user.Overall impact isn't huge - the nodes for the user are calculated only once per request and reused in both of the hooks. However, I think that this could be made even more efficient by creating an access table very much like the
node_access
table, that includes not only allow grants, but also the deny grants for all controlled nodes for all roles. We could update it every time the settings are updated, like we do withnode_access
. This way, we would only need to check against a couple of rows from that table, instead of recursively traversing vocabularies in each request.My notes from 9 apply to this patch as well.
Comment #12
karoop CreditAttribution: karoop commentedOne day I'll send a passing patch in one go... Parse error should be fixed now.
Comment #14
karoop CreditAttribution: karoop commentedSomehow had double-definition of a function in the patch, let's try again.
Comment #15
karoop CreditAttribution: karoop commentedComment #17
karoop CreditAttribution: karoop commentedComment #18
karoop CreditAttribution: karoop commentedResubmitting same patch due to git connection problem in the last test.
Comment #20
karoop CreditAttribution: karoop commentedWeird... The patch passes all tests in my environment with #1266674-10: Support other databases applied. Perhaps an oddity in the database layer is failing it? To see, I'm submitting a patch that includes all changes that I made, including 1266674, to make the code exactly the same as mine.
If that fails, we'll have to address the issue of compatibility with PHP 5.3 and MySQL 5.5.
Comment #21
karoop CreditAttribution: karoop commentedComment #23
karoop CreditAttribution: karoop commentedApologies for clumsy patching. I tested this one on PHP 5.4 and MySQL and fixed a couple of things. Should pass now!