An excerpt from http://www.sitepoint.com/multiple-editors-per-node-drupal-7/, by Daniel Sipos
One of the things that makes Drupal great is its flexible user permission system. The out of the box permissions grid we are all familiar with covers most uses cases of controlling what users can and cannot do. It is also very easy for module developers to create new permissions and roles that restrict the logic they implement.
Nevertheless, I have encountered a practical use case where the default configuration options are not enough. Namely, if you need to have multiple users with access to edit a particular node of a given type but without them necessarily having access to edit others of the same type. In other words, the next great article should be editable by Laura and Glenn but not by their colleagues. However, out of the box, users of a particular role can be masters either of their own content or of all content of a certain type. So this is not immediately possible.
In this article I am going to show you my solution to this problem in the form of a simple custom module called editor_list. Article nodes will have a field where you can select users and only these users (or those who have full access) will be able to edit that particular node. You can find the module already in this git repository and you can install it on your site for a quick start. Do keep in mind that it has a dependency on the Entity Reference module as we will see in a minute.
I will keep the code comments to a minimum to save space but you can find them in the repository if you want. Basic knowledge of Drupal 7 is assumed in the remainder of this tutorial.
Scaffolding
We first need the editor_list.info file for our module to get us going:
name = Editor List
description = Module illustrating a custom solution for having multiple editors on a node.
core = 7.x
dependencies[] = entityreference
Next, we need our editor_list.module file where most of our business logic will be located. So go ahead and create it and we will populate it as we go on.
Finally, though not covered here, we can have an editor_list.install file where we can implement hook_install() and hook_update hooks to create fields and/or deploy configuration. In the repository, you’ll find that I provided an install hook that already creates an entity reference field called field_editors and attaches it to the Article content type. If you are following along but not using the code in the repository, you should go ahead and create the field manually through the UI. It’s a simple field that references User entities and allows for unlimited selections. Nothing major.
Node access
Going back to our .module file, it’s time to implement our access logic. First though, to make things as flexible and reusable as possible, let’s have a simple function that returns an array of node types to which we apply our access logic:
function editor_list_node_types() {
return array('article');
}
Since we are only targeting articles, this will suffice. But we will use this function in multiple places so in case we need to target other types as well, we just have to update this array.
Next, let’s write another helpful function that returns all the user IDs set in the editors field of a given node. We will also use this in multiple places:
function editor_list_uids_from_list($node) {
$users = field_get_items('node', $node, 'field_editors');
$allowed_uids = array();
if ($users) {
$allowed_uids = array_map(function($user) {
return $user['target_id'];
}, $users);
}
return $allowed_uids;
}
I believe the function is quite self explanatory so I won’t go into details here. Instead, we can turn to our hook_node_access() implementation that gets called by Drupal whenever a user tries to do something with a node (view, edit or delete):
/**
* Implements hook_node_access().
*/
function editor_list_node_access($node, $op, $account) {
$node_types = editor_list_node_types();
if ( ! is_object($node) || ! in_array($node->type, $node_types) || $op !== 'update') {
return NODE_ACCESS_IGNORE;
}
$allowed_uids = editor_list_uids_from_list($node);
if (empty($allowed_uids)) {
return NODE_ACCESS_IGNORE;
}
if (in_array($account->uid, $allowed_uids)) {
return NODE_ACCESS_ALLOW;
}
}
So what’s happening here?
First, we use our previously declared helper function to get the list of node types we want to target, and we basically ignore the situation and return if the node type of the currently accessed node is not within our list or if the operation the user is attempting is not of the type “update”. Then we use our other helper function to check if there are any users in the editor list for this node and again ignore the situation if there aren’t. However, if there are, and our accessing user is among them, we return the NODE_ACCESS_ALLOW constant which basically gives the user access to perform the attempted operation. And that’s it.
You can check out the documentation for more information about how this hook works.
Let’s say you have admin users who can create and edit any type of content and regular authenticated users who cannot edit articles (apart from maybe the ones they created themselves). Adding one of these latter users to a node’s editor list would give them access to that particular node. And another great thing is that since this is all nicely integrated, contextual filters and tabs also take these dynamic permissions into account.
[Continue reading this article on SitePoint!](
)