| Project: | Taxonomy Access Control |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I have a vocabulary with numerous terms and want users to only be able to assign certain terms when creating pages based on their roles. Here's my setup:
I set up revisioning based on http://drupal.org/node/408018 and then setup TAC.
I have a role (math_drafter) that has the following perms: create page content, edit any page content, view revisions and edit revisions. I have a user with that role assigned. In addition, the user inherits things like access_content and some Module Grants perms by virtue of being an Authenticated User.
In TAC, I added one taxonomy term from that vocab, Math, with Allow access for View & Update, Ignore access for Delete, and checked the boxes for both Create & List.
Then, as that user, I try to create a page but the taxonomy dropdown box has no entries in it. If I enable the Create checkbox for Global default then all of the terms show up so I no that TAC is coming into play but without that enabled, there is nothing.
Any ideas why I'm not getting access to the term when creating the page? This is driving me crazy.
Comments
#1
I have the same problem. All roles are allowed to create events on my site, and without TAC they can choose any of the options for a taxonomy term. Once TAC is installed, all the options go away and even if I select "view" under a term for a particular role, that term does not show up in the dropdowns for creating content or editing current content that has that taxonomy term. Since it's a required field, they consequently can't save old content or create new content. Help please?
#2
Confirming.
No one should install or use this module until this is fixed. I'll personally try to switch to http://drupal.org/project/forum_access now, although rebuilding node access will take ages, again, oh well.
#3
i have same issue... but one more test... uid = 1 still has access to set tax; but also, so does any user in my "admin" role which has "all" perms set.
but i agree... module is busted.
#4
i am renegging my confirmation of this issue.. i think it is simply the CREATE privileges setting for the module.. i.e. it is by design.
this module certainly is a bitch to set up the first time you use it... and could likely have smarter defaults and maybe tell you when you need to rebuild perms.. but i think it does work as designed.. .:)
#5
I also agree with #4; "Create" privileges allow you to create a node tagged with the term in question.
What happens if node revisions are disabled? I've never been able to get TAC to function properly with revisions enabled.
Edit: #560334: TAC and revisioning is also about problems with revisions.
#6
I am unable to duplicate this bug, using the module grants and revisioning modules as per the article in the original post, with a role that has view, update, create, and list permissions for a particular term.
Can you please follow up with more information:
#7
This bug occurs when editing a specific revision of a node with Revisioning module, i.e. using
node/[NID]/revisions/[VID]/editpath. The taxonomy_access_db_rewrite_sql() function checks if the path is the create or edit form and fails with the revision edit path.I attached a very simple patch to resolve this issue.
#8
Aha!. I think this is related to #818212: Critical bug with node_revisions - vid as revision id versus vocab id.
Since the patch there is more broadly applicable (to any place vid means revision id rather than vocab id), could folks please test that patch instead and see if it resolves the issue? Add comments to that issue with the results of your testing.
(If the patch doesn't fix this issue, go ahead and set this issue's status back to needs review.)
#9
@xjm That issue describes a different problem (conflict "vid" field of node_revisions table with "vid" field of taxonomy tables when rewrites sql).
The source of this problem is this line of taxonomy_access_db_rewrite_sql():
<?php$op = (arg(0) == 'node' && (arg(1) == 'add' || arg(2) == 'edit')) ? 'create' : 'list';
?>
If the user is editing a node (add node form or edit node form) $op to be 'create', otherwise it is assumed to be a list of nodes (taxonomy/term/TID, frontpage, views, etc). The Revisioning module allows edit node revisions and $op it should be 'create' when the user edit a revision.
The patch attached to comment #7 fixed the problem for the following paths:
A better solution is to provide a hook for allow modules that have a custom node edit form to integrate with TAC.
Sorry my bad english hope you can understand.
#10
-- nevermind --
Config issue :) Make sure "list" is selected as the default for the vocabulary. Yeah. Like it says in the docs. :)
#11
#9: It is related. The query in this issue contains vid as revision ID instead of vid as vocabulary ID as well. Have you tested the patch? If it doesn't work, we should try to find a solution that addresses both issues. Excluding specific paths is a very fragile way to resolve the issue.
#12
Well - after many months of having been pulled off of this onto other projects, I'm finally able to get back to working with this issue. I was sort of able to get it to work - but not really. It may be fine if you only have a one level taxonomy but, if you have a multi-level taxonomy and need any sort of granular control - not so much...
Here's how I had to set it up on a bare bones install.
Taxonomy looks like this:
- Depts
- |--> Dept1
- |--> Dept2
- Offices
- |--> Office1
- |--> Office2
User A has role Office2_drafter and I want them to be able to only create & edit content for Office2. In Taxonomy Access Control permissions, that role has to have Create permission for both Office2 and Offices terms. As you would think, this lets them create pages under the Offices term but, if they don't specifically have View access to Offices, that results in an Access Denied page after the node is created. This is in spite of the fact that the default global permission for authenticated users is to allow View. (Oh, and it works the same whether the patch from #7 is applied or not.)
This just seems totally unintuitive to me and I'm really at a loss as to how to make this work. The end result that I'm trying to get is granular enough control so users can access everything on the site but only create/edit things in their department. And then I need to layer controlled publishing on top of that.
Any ideas? I'll be happy to provide any other information that I can about what I've tried or how it's set up.
EDIT: Just found #112307: Cannot create node in taxonomy term without create permission for parent term which looks like it may fix the issue. Will investigate over the next couple of days and update.
#13
@llang I got it working but I switched to tac_lite because it's easier to configure. It IS a bit less powerful, as advertised, and if you have to set up tonnes of "access scenarios" I don't know how it'd be for performance. But it's safer: for example, it lets you only one or two selected vocabularies for access control, so there's far less chance of default configurations on vocabs you don't care about affecting those you do (which happened to me). Give it a whirl if it suites you use case.
#14
I committed the fix for #818212: Critical bug with node_revisions - vid as revision id versus vocab id.
http://drupal.org/cvs?commit=403922
New dev build should be available within 24 hours. It may resolve this issue as well, but since I have never been able to duplicate this bug I do not know for sure. If it does not, please post a followup and reopen. In that situation, we may need to implement a different fix to get this to work. See remarks in #112307: Cannot create node in taxonomy term without create permission for parent term #34.
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
The patch available in #881210: No list or create permissions on any terms may result in incorrect use of default on save should resolve any remaining problems. If you still encounter this bug or anything like it, please test the patch from that issue with the latest dev build of TAC. Direct link to patch:
http://drupal.org/files/issues/tac_881210-9.patch