Grant/restrict access according to node's author & moderation state

Question

I'm trying to bypass some of the permissions set by Workbench Moderation, only under specific circumstances. For a specific content type, I need the users of a specific Role to be able to: - View all Published nodes of that content type (this works fine as it is quite general) - View Unpublished nodes only if the nodes 1. are related to them (through Entity Reference field) or 2. they have created themselves. - Edit nodes only if they are related to them (through Entity Reference field) or nodes they have created themselves. This should be allowed only in a specific State.

I've tried implementing hook_node_access_records() & hook_node_grants() hooks in my module but this doesn't seem to work. In the following example, the conditionals are different than what's mentioned above but the logic is the same:

function mymodule_node_access_records($node){
    $grants = array();
    if ($node->nid == 1234 && $node->uid == 99) { //(example conditions)
        $grants[] = array(
            'realm' => 'mymodule',
            'gid' => 123,
            'grant_view' => 1,
            'grant_update' => 0,
            'grant_delete' => 0,
            'priority' => 0,
        );
    }
    return $grants;
}

function mymodule_node_grants($account, $op){
    $grants = array();
    if (($op == 'view' || $op == 'update') && $account->uid == 99) { //(example conditions)
        $grants['mymodule'] = array(
            123,
        );
    }
    return $grants;
}

This does add a line in node_access table where only grant_view has a value of 1. It should just allow related users to view the specific (unpublished) node but not edit it.

UPDATE: I installed Devel node access and here are my findings for the test case above (node 1234 is Unpublished, user 99 is author):

• Test User can View the node - OK
• Test User can Edit the unpublished node (non-Published draft) - NOT OK
• Test User cannot Delete the node - OK
• Test User can Moderate the Unpublished node (allowed transitions set by WM config.) - OK

Here is what Devel actually displays on that node's view page:

• Create: YES: by node (permissions) - OK
• View: YES: view own unpublished content - OK
• Update: YES: by node (permissions) - This should be overridden by my access module
• Delete: NO: no reason - OK

How can I override this edit permission with my module? I'd eventually like to expand the functionality of this module to cover other cases as well.

Answer 1

Access to the 'node/%node/edit' path is done by node_access(). It first checks some global permissions, and then invokes hook_node_access() to check for explicit allows and denys. node_node_access() checks the permissions at admin/people/permissions, and will return NODE_ACCESS_ALLOW if set.

Based on your debug information, it looks like a permission is allowing the update operation, so the grants aren't being checked.

I think you need to do one of two things.

You could implement your own hook_node_access() that returns an explicit NODE_ACCESS_DENY when you need to. This will override any explicit NODE_ACCESS_ALLOW.

The other option is to remove the explicit edit permissions for your content type(s), and then use grants. You would have to update the logic in your hooks to cover all of the cases where someone can edit the content, and not just your special cases.

Make sure you also read up on node access rights (see also this article), as they can be confusing until you really grasp how they work. Just remember

• If using hook_node_access(), a NODE_ACCESS_DENY will override a NODE_ACCESS_ALLOW, but not the other way around.
• If using grants, the default is to deny to all, and then allow to some. It's early, and I can't quite remember if you can explicitly have a grant that denies one that has already been granted.

Answer 2

A helper module that I use for managing node access is ACL .

The ACL module, short for Access Control Lists, is an API for other modules to create lists of users and give them access to nodes. It has no UI of its own and will not do anything by itself

What I suggest is that instead of handling the grants yourself, you outsource it to ACL. The module has a simple (YMMV) to use high-level API that let you grant individual users access (and revoke it).

The documentation is a little sparse, but on the ACL project page existing client projects are listed. I learnt how to use it by reading the source code of those.

Alternatively, you can read the source code of ACL to see how to do low-level manipulation of permissions.

If you end up writing your own module, the introduction to this page gives a good introduction to how Drupal's node access system works. In particular, you should be aware of:

Node access modules always GRANT access and never restrict it. (It is a whitelisting rather than a blacklisting system.)

I understand you already use DNA (Devel Node Access), but if somebody else stumble across this: DNA (part of the Devel project) is absolutely essential if you are going to debug node access.