Drupal Association members fund grants that make connections all over the world.
Taxonomy Access Control (a.k.a. TAC) uses Drupal core's node access system. TAC already provides very fine-grained and flexible access control, so it has not been specifically designed to work with any other access control modules. However, it is possible to install multiple access control modules that all use Drupal's core node access system. This page provides some information on what to expect when you use TAC with other access control modules.
Note: Combining multiple access control modules can be difficult. If at all possible, it is recommended you avoid using multiple access control modules together. If you choose to use multiple modules, test your access control configurations thoroughly on a non-production site.
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
- Background information: Grants are additive
- Grant priority
- Alternative configuration: Module Grants
Background information: Grants are additive
Under normal circumstances, access control modules' grants are additive. This is a feature of Drupal's node access system. For any given node, Drupal asks all installed access control modules whether that module grants View, Update, and Delete permissions to that node (by invoking hook_node_access_records()). Each module returns either true (
1) or false (
0) for each of View, Update, and Delete.
If any one module returns true for a grant type (View, Update, or Delete), then the user receives that grant for that node. (This is true only when other access control modules return the same grant priority as TAC. See Grant priority below for more information.) In other words, the grants from multiple modules are evaluated together with OR.
This means if TAC does not grant access to a node, but another module does, the user will still have access to that node. This is why it is important to configure core permissions properly: if the core node module grants a user access to edit a node, TAC cannot normally revoke that access. The reverse is also true: if TAC grants access to a node, other modules cannot normally revoke this access. Keep this in mind when configuring TAC's global defaults in particular.
It is possible for access control modules to specify what the priority of their grants should be. (Developers may wish to look at the API documentation of node_access_acquire_grants() for more information.) The node access system looks at only the highest priority grants when determining node access. TAC's priority is zero (
0). TAC does not support changing this priority; however, other node access modules may set their priorities higher or lower than zero.
At present, TAC provides node access records for every node. This means that if another module has lower priority than zero for a given node, its grants will be ignored. (Conversely, if any module returns a higher priority for a node, TAC's grants will be ignored.) Untagged nodes use the global default for the role; tagged nodes receive grants according to the permission configuration of the node's term(s). (Remember: Access is denied by default.)
It is a common misconception that changing an access control module's weight changes the priority of its grants. This is not the case. A module's grant priority is determined only by its hook_node_access_records().
(Examples needed -- please add examples here or suggest them in the comments.)