Set access set at partent term level?

This 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.

What 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?

Closing duplicate issue #2209657: New Child pages do not inherit taxonomy and referenced a fixed issue for D6 that is this exact issue

I 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.

Oops, parse error in patch! This should work.

OK, 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.

This 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 the hook_node_access(), so they were showing the inaccessible items anyway. To fix that, I have implemented the hook_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 with node_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.

One day I'll send a passing patch in one go... Parse error should be fixed now.

Somehow had double-definition of a function in the patch, let's try again.

Resubmitting same patch due to git connection problem in the last test.

Weird... 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.

Apologies for clumsy patching. I tested this one on PHP 5.4 and MySQL and fixed a couple of things. Should pass now!