Drupal 7 Module Development

Chapter 8
If we had accidentally run the permission check on the $account object, then we
might return the wrong permissions. For clarity, let's take a look at a more complex
example. In the following snippet, we want to show a list of all content types that a
user can create. Our function will begin much like the last implementation, and then
get more complex.
/**
* Implement hook_user_view().
*/
function example_user_view($account, $build_mode) {
if (!user_access('view content creation permissions')) {
return;
}
// Get the defined node types.
$node_types = node_permissions_get_configured_types();
if (empty($node_types)) {
return;
}
// Make an array for the list output.
$list = array();
foreach ($node_types as $type) {
if (user_access('create ' . $type . ' content', $account)) {
// Get the human-readable name of the content type.
$list[] = check_plain(node_type_get_name($type));
}
}
The preceding code snippet defines a function that pulls the permissions for
the account being viewed by the current user. Our two sets of permission checks
operate on different user accounts.
The important piece here is the user_access() check that we run for each node
type. If we were to leave off the $account, then this check would assume that we
wanted to know what content types the current user could create. Doing so would
mean the same results would appear no matter which user account page we viewed.
Note: The use of the $account object instead of the $user object is
a standard practice of Drupal, and a good coding practice. In Drupal,
the $user object is a global value, and it would be a mistake to pass it
(sometimes by reference!) when we only mean to extract information
from it. Instead, lookup functions like hook_user_view() always act on
a copy called $account. This pattern occurs frequently in Drupal core,
and you should follow this best practice.
[ 215 ]