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:

On this page

  1. Grant types
  2. Permission options
  3. Global and vocabulary defaults
  4. Good to know

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

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

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

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

jamesrward’s picture

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.

Branjawn’s picture

And you never will! Woohahaha...

No, seriously, what does "ignore" mean in the TAC context? Doesn't make sense to me either.

justingeeslin’s picture

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.

xjm’s picture

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. :)

NikLP’s picture

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

mcfilms’s picture

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

augbog’s picture

I have updated the documentation regarding the Ignore tag. Hopefully it is correct? If not, please fix it.

MatthijsG’s picture

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

Michelle’s picture

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

Bockereyer’s picture

No it isn't in Configuration -> People -> Taxonomy Access Control

jbarchuk’s picture

D7 Structure --> Taxonomy
Found via Help --> Taxonomy --> scroll down

solerous’s picture

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.

polyja’s picture

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

webjazz’s picture

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!

webatelier’s picture

Did you ever find a solution for this problem ?
I'm struggling with the exact same problem now ....
Thanks in advance

quiqueh’s picture

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)