Apart from the permissions system in Drupal, it is possible to implement a system based on grants. This relates nodes to realms (based on role, term references or other attributes related to users), granting (or denying) access. In the table node_access rows consist of 6 values, (nid, gid, realm, grant_view, grant_update, grant_delete).

E.g. (3, 5, 'superusers', 1, 1, 1).

• If the user is trying to access node 3,
• if the user is related to the realm superusers
• with grant id 5,
• then the user can view, update and delete the node.

E.g. (7, 4, 'mice', 1, 0, 0).

• If the user is trying to access node 7,
• if the user is related to the realm mice
• with grant id 4,
• then the user can view the node.

How exactly realms and grant ids are used, depends on the module using it.

http://api.drupal.org/api/drupal/modules!node!node.api.php/function/hook_node_grants/7

An example: The ABT module

• I create a taxonomy, or use the existing taxonomy tags.
• I create a content type, with a term reference to this taxonomy.
• While saving this field, I will be asked further details about this field.

• Likewise, I add a field to the user profile, a term reference to the same taxonomy.

• I create some content in my new content type, and add a tag.

• I create a new user, and add the same tag.
• Now node_access looks like this:

• The new table abt_map will now look like this:

How did ABT do it?

• there's more info in abt_map
• the gid in this case is the same as the tid / term id for the term in question ("testterm")
• the realm is named after the module (abt) and the field (field_termref)

What about a hierachy?

• Example: term "Europe" is above term "Denmark"
• user is related to "Europe"
• node is related to "Denmark"
• then the user has access to the node
• (the other way around doesn't work, as it probably shouldn't)

What about a combination of tags?

• content (jeans) and users are tagged with languages and brands
• specific pair of jeans: German Calvin Klein
• if user is tagges with either "German" or "Calvin Klein", there is access

An example: The Taxonomy Access Control module

• I use the taxonomy called tags.
• I create a content type, with a field referencing this taxonomy.
• I create content with a term for this reference ("version1.0").
• I create a role called "mayversion1.0".
• I configure Taxonomy Access Control:
  • Authenticated users get a new row, based on the term, with deny in all 3 columns.
  • mayversion1.0 users get a new row, based on the term, with allow in all 3 columns.
  • (When 2 different roles say allow and deny, allow wins.)
• I create a new user. It is related to the role mayversion1.0.
• This new user can access my content.

How did TAC do it?

• there's more info in taxonomy_access_default:

• and taxonomy_access_term:

• the gid in this case is the same as the rid / role id for the role in question:

• the realm is named by TAC, "taxonomy_access_role"
• role 1 = admin, role 2 = authenticated user, role 4 = mayversion1.0
• node 3 = my content
• vocabulary 0 = tags

What about a hierachy?

• Example: term "Europe" is about term "Denmark", and were so when TAC was configured
• role is related to "Europe"
• node is related to "Denmark"
• then the user has access to the node

The module Workbench Access does not use node_access. Also, it only controls create/edit rights, not view rights. Video.

Note:

• Term access only exists in a development version.
• Content access only exists in beta.
• Nodeaccess only exists in a development version.
• Taxonomy access control lite only exists in an "other" version.
• Access control kit only exists in a development version.
• Menu access is only for drupal 6.
• Taxonomy Access Control is minimally maintained.