Posted by michaeldhart on April 7, 2009 at 3:24pm
Jump to:
| Project: | Taxonomy Access Control Lite |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I recently installed view-own on a 6.10 site currently running Taxonomy Access. At first it appeared that view_own was simply not working. I was able to set permissions, but they had no effect despite rebuilding permissions. Tried disabling Taxonomy Access and rebuilding permissions. Then view_own took effect. Re-enabling Taxonomy Access and rebuilding permissions caused view_own to lose effect once again.
Comments
#1
There can be some permission conflict, try to change the weight of the module.
If you want to give priority to view_own module, try increase it.
#2
I have the same problem even after adjusting weight.
Is there some way to make these two work together (tacl and view_own)?
#3
Can you dump access rows from node_access table for specified node?
SELECT * FROM node_access WHERE nid = YOUR_NODE_NID#4
With tac_lite weight = 9 and view_own weight = -9
nid gid realm grant_view grant_update grant_delete
1 1 tac_lite 1 1 1
1 3 view_own_owner 1 0 0
1 5 view_own_role 1 0 0
and got the same query results with tac_lite weight = -9 and view_own weight = 9
after rebuilding permissions and re-saving the node
Hope that helps
Thanks a heap
#5
Basically tac_lite overrides view_own permissions giving full access to the node. You need to find some solution for tac_lite to disable giving access to all nodes by default.
#6
TAC and TAC Lite are completely different modules with wholly different codebases at this point, so nudging the issue along to the correct queue (at least for the recent posters)... although I'm not sure I'd agree it's a TAC Lite issue. However, interested parties might want to take a look at this article:
http://drupal.org/node/408816
In general, it matters how you want one module to override another. Modules generally can grant additional access, but in most cases will not revoke access other modules have granted.
If the behavior in question is why users can view all posts under Term A when TAC/TAC Lite/etc. gives them an "Allow" for Term A (even if the user only has "View Own" for the content type), I'd say that's by design. If, however, TAC/TAC Lite/etc. is preventing the user from seeing their own nodes when they have "View Own" checked, then that's something that needs to be explored further.
In the case of TAC, consider changing your global default to something more or less permissive (depending on whether users are being denied access when you want to allow it or vice versa). Or, take a look at Module Grants (in the article above) and see if that helps give you the behavior you want.
#7
First weights don't matter for the node_access table. Here's how the logic works...
If a hook_access() grants someone access to do something, they can do it - this is how permissions work.
If hook_access() returns null, then the node_access table is consulted. If any entry in node_access grants the permission, then the permission is granted.
So order doesn't matter. This makes it hard to combine two node_access modules in D6. There's a patch to D7 making this possible, and maybe a backport to 6??? [#http://drupal.org/node/309007]
Without that any combination of two node_access modules will be delicate at best. For debugging I recommend the devel_node_access.module which comes with http://drupal.org/project/devel.
Just looking at your node_access table I see you've used tac_lite to grant all access to node 1. If you're trying to do something else, you have to configure tac_lite differently or tag the node differently.
#8
#309007: Add drupal_alter() after hook_node_access_records() #88