Drupal 7 Module Development

Node Access
Here we see a distinct difference between Drupal 7 and Drupal 6 (and earlier): any
module may respond to this access check. Prior to Drupal 7, only modules that
defined a node type could respond, using the old hook_access() function. This
constraint made it difficult for module developers to modify the business logic for
node_access(). This is a major change in the Drupal API, and one which we will
explore in some depth.
The constants NODE_ACCESS_DENY and NODE_ACCESS_ALLOW are set by
node.module. We will look at these later in the chapter.
Notice also the note in the comments: If no module specified either allow or
deny, we fall back to the node_access table. The execution order of Node
Access hooks matters. When we consider the logic for our business rules, we must
remember that other modules may also have a stake in the access rights to a node.
So far, we're up to five return statements in the code.
Access to a user's own nodes
The next clause is an exception for handling nodes created by the current user:
// Check if authors can view their own unpublished nodes.
if ($op == 'view' && !$node->status && user_access('view own
unpublished content', $account) && $account->uid == $node->uid &&
$account->uid != 0) {
$rights[$account->uid][$cid][$op] = TRUE;
return TRUE;
}
Drupal assumes that unpublished content should not be visible to users. However,
the view own unpublished content permission exists to allow authenticated users
to see their content even if it has not been published. Unless a third-party module
intervenes, only users with this permission, bypass node access or user 1 may
view unpublished content.
Invoking the node access API
Now that Drupal has accounted for that special case, the code falls through to the
{node_access} table for checking permissions.
// If the module did not override the access rights, use those set
// in the node_access table.
if ($op != 'create' && $node->nid) {
[ 248 ]