Module Grants

Module Grants main raison d'etre is to allow modules that deal with unpublished content and fine-grained access control (aka "grants") to work in the expected fashion. It works particularly well in publication workflows and revision moderation. Check out the step-by-step tutorials for Revisioning.

Module Grants however does come with a handy feature of its own. Administrators and roles permitted by the administrator will see an new navigation menu item Accessible content which shows a list of all content the logged-in user currently has access to, as granted by the sum of all access modules on your system. Depending on the permissions set under Adminisiter >> User management >> Permissions users are able to filter this list using up to 7 tabs. When all tabs are enabled, the first row of tabs filters content the user created, last edited, can edit or can view. The second row applies additional filtering by publication status: currently published, not published or either.

To install:

1. Place the module_grants folder in your sites/all/modules directory.
2. Enable the module under Administer >> Site building >> Modules
3. Under Administer >> User management >> Permissions, section module_grants module you can control access to the various filtering tabs on the Accessible content page. Please note that in versions prior to 10 Nov '09 each role that is to view the accessible content list must have at least the "access I Lst Modified tab" and "access Published tab" permissions checked. If not the Accessible content menu item may not appear or users may get the message "You are not authorized to access this page."
4. There's usually no need to tick "administer nodes", which is good because "administer nodes" equates to almost god-like powers that you wouldn't normally give to most users.
5. If required, install and enable modules for content access control as required. Typical examples are Taxonomy Access Control (or use TAC Lite) and Workflow.

Important: for a role to view unpublished content the "view revisions" permission (User management >> Permissions, node module section) must be ticked.

Module Grants has one admin setting (Administer >> Site configuration >> Module grants). The multi-module access leniency toggle was introduced to make the operation of multiple content access control modules together even more natural, especially when on the same site some content types are involved in workflow and/or taxonomies while other content types are not.
This checkbox has an effect only when two or more content access modules are enabled and one of the modules makes no statement about a node being accessed. If this box is checked ("lenient", the default), then a content access module saying nothing (via the node_access table) about the node in question will be deemed to be ok with the user having access to it. If not checked ("strict"), then a module saying nothing will be taken as a "deny access".

Appendix: permissions & grants in content access operations

At the heart of content access in drupal lies the node_access() function of the node.module. It gets called for each of the various access operations (create, view, edit, delete) attempted on a piece of content (i.e. a node). There are two tiers of access control involved. I'll call them permissions and grants and promise to avoid speaking of granting permissions or permitting grants. For any user other than someone having the “administer nodes” permission the following apply (simplified):

1. core permissions: these are the role-based permissions that can be flicked on in the node module section of the User Management>>Permissions page; these include the edit/delete tick boxes for own or others' content (4 per content type); if a ticked box applies to the content in question, then access is given immediately
2. if none of the ticked boxes apply, then
   a. if the published-flag is set, access to content is as per the view/update/delete grants in the node_access table, which may be populated by any custom module
   b. if the published-flag is not set, then access is denied (except for the case of an author viewing their own content)

The first thing to notice about the above is that for any custom module to even get a look in, you must not tick any of the edit/delete boxes pertaining to the content types in question, as they'll allow access before the custom module is given a chance to decide what it wants to do.
Secondly, modules for fine-grained access control (such as Workflow Access, TAC, TAC-Lite) tend to rely on grants in the node_access table for their implementation and are therefore rendered impotent when dealing with unpublished content, because of the way node access is wired into the drupal core (point 2b). The behaviour in point 2 is due to what may be one of the most discussed single lines of code in the drupal community {1}, {2}. Several developers have suggested removing the dependency on the published flag and some have in fact done so in their own installations {2, #20, #6} by modifying the core node module. However this requires you to make the same modification again every time a new drupal version comes out. Unknown side effects could pop up too {2, #21}. We felt it to be preferable to develop a custom module that doesn't require any core code to be patched, which is what we did in introducing the Module Grants module.

Finally, it should be noted that when multiple modules record grants in the node_access table, the node_access() function ORs (rather than ANDs) the module grants together. This is usually fine within a module, but when combining grants from two or more modules AND-ing them together often makes for more natural behaviour. OR-ing the grants has the undesirable effect of one module re-opening the door to content when access was already denied by another. For instance, when Taxonomy Access Control (Lite) is installed and an "entertainment" author can't view, say, a sports article because they don't have access to the “sports” term, then it would be wrong if after installing the Workflow module the author suddenly does have access, when another user (eg a moderator) puts the content in the “editable” state (and by the workflow grants authors can access "editable" content). The Module Grants approach is therefore to AND grants across modules.

References

Drupal forum posts on this topic in the context of workflow, taxonomies and revision moderation
{1} #346021: workflow view/edit/delete permissions for roles & states not working, comments #7, #8, #14
{2} #156028: Workflow nodes must always be published for access controls to apply, comments #10, #20, #21
{3} #218755: support revisions in different states, introduction and comment #9
{4} #372724: Workflow integration with revisions - states for revisions

Further reading

{5} Book: Pro drupal development, 2nd edition, p. 162
{6} Node access control in drupal