Taxonomy Access Control (a.k.a. TAC) allows the user administrator to control access to nodes indirectly, by controlling which roles can access which categories. The administration page is at User management > Taxonomy Access Permissions (in Drupal 6, admin/user/taxonomy_access; in Drupal 7, admin/config/people/taxonomy_access).
Permissions can be set differently for each user role. Be aware that setting Taxonomy Access permissions works only within one user role and within the module. (For users with multiple user roles, see section Good to know below.)
Note: If you are not familiar with how Drupal's node access system works, see these resources:
- Handbook page: Overview of Node Access modules
- Drupal node access explained has some helpful points
- John VanDyk's book Pro Drupal Development is also informative (the section on node access begins around page 159; see especially the flowchart on page 162).
On this page
Grant types
On the category permissions page for each role, administrators can configure five types of permission for each term: View, Update, Delete, Add tag (formerly List), and View tag (formerly List):
-
View: Grants this role the ability to view nodes with the term. (Users must also have this permission to see nodes with the term listed in Views.) The role must have access content permission at
admin/user/permissions#module-node
. -
Update, Delete: Grants this role the ability to edit or delete nodes with the term, respectively. The role must not have edit any [type] content or delete any [type] content permission at
admin/user/permissions#module-node
if you wish to control them with TAC. -
Add tag: Grants this role the ability to add the term to a node when creating or updating it. This does not give the role the ability to create nodes by itself; the role must have create [type] content permission at
admin/user/permissions#module-node
in order to create new nodes. -
View tag: Whether this role can see the term listed on node pages and in lists, and whether the user can view the
taxonomy/term/x
page for the term. This does not control whether the role can see the nodes listed in Views, only the term.
View, Update, and Delete control the node access system. View tag and Add tag control the terms themselves. (Note: In previous versions of Taxonomy Access Control, there was no View tag permission and its functionality was controlled by the View permission.)
Permission options
View, Update, and Delete have three options for each term: Allow (A), Ignore (I), and Deny (D). Indicate which rights each role should have for each term. If a node is tagged with multiple terms:
- Deny (D) overrides Allow (A) within a role.
- Both Allow (A) and Deny (D) override Ignore (I) within a role.
- If a user has multiple roles, an Allow (A) from one role will override a Deny (D) in another. (For more information, see section Good to know below.)
- Ignore can be seen as a weak form of deny. By default, it will simply not provide access to the permission if selected. This can be overwritten if a user has multiple roles and any of the roles has either an Allow or Deny associated with the permission. Please note that if a user has multiple roles including both Allow and Deny, Allow will take precedence (see below in Good to know)
Add tag and View tag have only two options for each term: Yes (selected) or No (deselected). Indicate what each role should be allowed to do with each term.
Important notes
-
Custom roles will inherit permissions from the authenticated user role. Be sure to configure the authenticated user properly at
admin/user/taxonomy_access/edit/2
. -
The Deny directives are processed after the Allow directives. (Deny overrides Allow.) So, if a multicategory node is in Categories "A" and "B" and a user has Allow permissions for View in Category "A" and Deny permissions for View in Category "B", then the user will NOT be permitted to View the node.
Access is denied by default. So, if a multicategory node is in Categories "C" and "D" and a user has Ignore permissions for View in both Category "C" and "D", then the user will not be permitted to view the node.
(If you are familiar with Apache mod_access, this permission system works similar to directive: ORDER ALLOW, DENY).
Global and vocabulary defaults
The vocabulary default, just underneath the vocabulary title, sets the permission that will automatically be given to the role, for any new terms that are added within the vocabulary. This includes terms that are added via free tagging.
The global default, at the top of the form, determines the grants the role receives for untagged nodes (including nodes with terms that are not in controlled vocabularies). Keep in mind that access is denied by default, so if you want TAC to grant a role access to untagged nodes, set the global default to allow for that grant and role.
Good to know
-
Users with multiple user roles: Allow/Ignore/Deny options are interpreted only within one user role. When a user belongs to multiple user roles, then the user gets access if any of his/her user roles have the access granted.
In this case, permissions for the given user are calculated so that the permissions of ALL of his user roles are "OR-ed" together, which means that Allow in one role will take precedence over Deny in the other. This is different from how node access permissions (for multi-category nodes) are handled within one user role, as noted above.
- Input formats: Node editing/deleting is blocked, even when the user has Update or Delete permission to the node, when the user is not allowed to use a filter format that was used when the node was saved.
Comments
What does "Ignore" do?
The documentation says "Access is denied by default. So, if a multicategory node is in Categories "C" and "D" and a user has Ignore permissions for View in both Category "C" and "D", then the user will not be permitted to view the node."
What exactly is being ignored? I would have assumed that by ignoring a permission the system would just fall-back on the existing permissions for access content and the user would be able to see the content in this case. Allow and Deny make sense to me but in this context I have no idea what Ignore means.
ignore...
And you never will! Woohahaha...
No, seriously, what does "ignore" mean in the TAC context? Doesn't make sense to me either.
To Ignore is to neither Allow or Deny
To Ignore is to neither Allow or Deny.
I see your point.
If you set Ignore, it doesn't mean the the TAC module will ignore it.
If you want the module to not alter the permissions for a certain role, you should not enable permissions for that role through the TAC module.
See above
See at: http://drupal.org/node/31601#perm
Deny overrides Allow. Allow overrides Ignore. So, ignore is like a weak deny that gets... well... ignored if there is a stronger grant present. :)
Errrm
Someone really needs to add "what actually happens when you select ignore". It's not clear from the docs above (@ 8 Feb 2012) or indeed the comments.
There needs to be a "what happens..." for each individual radio/box on the config line to explain this fully. I'm not dumb, but I don't get it...
Edit: in fact, there's a lot of words here, but it seems like an annotated picture might be the best thing (or at least a sound addition)?
Drupal Build & Development in Nottingham by Kineta Systems
Nominating you
See that edit tab up at the top of the page? YOU can be that someone to help document TAC. The best way for community-based software documentation to get better is for people to identify weaknesses and then work to solve them.
A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com
Updated
I have updated the documentation regarding the Ignore tag. Hopefully it is correct? If not, please fix it.
Replying to an old comment,
Replying to an old comment, but maybe someone who need this, reads this :-)
Ignore is helpful when you've another acces-module. I use Content Access and on admin/structure/types/manage/[contenttype]/access, the weight is set to -1.
Drupal first looks to CA, then TAC. When a value is set to ignore in TAC, the setting from CA is used. But, allowing or denying in TAC is overriding CA.
Example
Contenttype page, with term foobar
CA has: role1 can edit type 'page'
TAC has:
- default deny
- term foobar: ignore.
A page with the term foobar selected, should be editable by role1.
======
There are 10 people who can count binary
They who can and they who don't
D7
I know these docs are for D6 but I was trying to use the D7 version and could not figure out where the settings were. Turns out you go to Configuration -> People -> Taxonomy Access Control.
Michelle
D7
No it isn't in Configuration -> People -> Taxonomy Access Control
D7
D7 Structure --> Taxonomy
Found via Help --> Taxonomy --> scroll down
Unable to edit content
I followed the setup instructions at http://drupal.org/node/1313876 as best I could, but when I click on a page with a given tag in an "editor" role, the body says "This field has been disabled because you do not have sufficient permissions to edit it." I'm using Drupal 7 with the Revisioning and Workflow modules as well. I have "view revisions" enabled for the editors as well workflow permissions to view and administer those. Other than that, nothing else is set for the editor except the TAX options suggested in above link.
Access content permission
What do you mean by "The role must have access content permission" ?
I don't find this permission for the node module...
Sbd could help me ?
Thanks...
Multiple Groups
Hopefully i came to the right place. It says it quite clearly that in the Good To Know section that when a user is in several groups, the user will get access to a node if one of the groups he is a member of grants acces to it.
Have a case where i have two groups. One group is for store managers. The second for a store a given employee works in. Each store has its own store group. A store manager would be a member of both groups because he needs to see content intended for store managers and for the store he works. But with taxonomy access can not create content that would be intended for the store manager of store A only. (For the reason mentioned above). The content would simply be visible to all members of the store manager group AND to all
members of the group of Store A.
Does anyone know of a solution for this problem? I can not create groups per location because there are a hundred stores and some 20 different job descriptions. I would need 2000 groups which makes the system impossible to manage.
Any help is highly appreciated!
Did you ever find a solution
Did you ever find a solution for this problem ?
I'm struggling with the exact same problem now ....
Thanks in advance
Here are my 2 cents
Here are my 2 cents
Group - Store Manager - Store group
Role - Create content (I) - Create content (D except for Taxonomy term refering to his Store (A))
Role 2 - View content (A) - View content (I except for Taxonomy term refering to their Store (A))
Based on Taxonomy (Store: Store A, Store B, etc)