Drupal 7 Module Development

• Can this user bypass node access?
Chapter 9
New in Drupal 7, the bypass node access permission has been split from the
administer nodes permission. This permission allows super-users to ignore
all node access rules (including those enforced by hook_node_access()).
Normally, this permission is only retained by user 1, but on some sites, select
roles should always be allowed to view all nodes.
• What node access permissions does this user have?
Here, the function calls node_access_grants() to determine what node
access permissions the user account has been granted. These grants are
returned by your module's hook_node_grants() function. Each returned
grant is used to create a new OR clause in the final node access query.
Note that we said OR clause. This is crucial. Node access in
Drupal is still a permissive system. If you are using multiple
node access modules and one grants access, that access
cannot be taken away by another node access module's
grants. There are, however, ways to enforce "deny" grants
through either hook_node_access() or hook_node_
grants_alter(), which we will discuss later.
• What action are we performing?
The last question checks the operation being performed (View, Update, or
Delete) in order to add the proper access clause against the grant_view,
grant_update, or grant_delete columns of the {node_access} table.
Unlike hook_node_access(), the query runs against the {node_access} table
and does not care which individual node we are trying to view, update, or delete.
Instead, the node access system here provides a layer of abstraction so that listing
queries can be properly filtered according to the site's access rules.
{node_access} table schema explained
The {node_access} table works by storing the necessary information for running a
proper JOIN to the {node} table based on the conditions described above. To fully
understand how the above query example works (and to plan your node access
module), let's examine the structure of the table itself.
[ 263 ]