Taxonomy Access Control: Restrict user roles to access specific categories only

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

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.