Drupal 7 Module Development

Chapter 9
A few things to consider when returning your node grants.
• Your module may assert one or more 'realms' as appropriate to your
business logic.
• The 'realm' must be a string unique to your module. Namespace your grant
with the name of the module. If you only store one grant, use the name of the
module as the realm.
• The three grants are each checked separately to determine permissions. This
means that you may define all three grants (view, update and delete) in a
single statement.
• The 'priority' element is deprecated for Drupal 7. It can be used to discard
the grants set by other modules. However, this is best done through the
new hook_node_access_records_alter(). (See http://drupal.org/
node/686858 for details.)
• Your grants declarations must be integers (0 or 1) and not Boolean TRUE or
FALSE. Drupal 7's database layer uses stricter variable typing than Drupal 6
and below, so be sure to update your legacy code.
• The {node_access} table does not distinguish between published and
unpublished nodes. Only trusted users should be given permission to access
unpublished content.
We have now established our rules in the database. Let's examine the second part of
the node access system.
Right now, if we save a node with our module in this form, nothing
happens. Why? Because the Node Access API assumes that your
module also implements hook_node_grants(). Without that
hook, your records will not be stored. Drupal does this to save
database overhead associated with storing unused records.
Using hook_node_grants()
For every page request involving nodes, Drupal queries the enabled modules for
the node access grants that are in force for the current user. Modules respond to this
query using hook_node_grants().
Unlike hook_node_access_records(), which is node-centric, hook_node_grants()
is user-centric. The hook passes two parameters:
• $account – the user object of the person viewing the page.
• $op – the operation being performed (view, update or delete).
[ 269 ]