Module Grants, Revisioning and Content Access Control problems

Hi dleong,
Have you looked at or tried the tutorials below and compared your requirements to what these three increasingly more elaborate publication workflows are capable of, i.e. have you done a gap analysis?
o Revisioning at its simplest
o Revisioning with categorised content , using TAC-Lite
o Revisioning with state-based content access control, using Workflow

Note, that the creation of new and moderated revisions can be switched on/off per content type (go to /admin/content/types and press the edit link for the content type in question; then look under "Workflow settings".
Together with role permissions that should get you a long way.

You don't mention anything about taxonomies (eg departments, regions...),so it is not clear to me why you feel TAC (or TAC-Lite) would be required in your case.
The Workflow module might be useful (in combination with Revisioning, see above tutorial)... again it depends on your exact requirements -- if you follow the tutorials above you'll find out what's missing for you, so that you can ask more specific questions.

What is it in particular that makes you convinced that Content Access and Node Privacy By Role are (both) mandatory for what you are trying to solve?

See also: http://drupal.org/node/410572

Hi Dennis,
Before we jump to solutions (to what you may not need), shall we take stock for a minute and clarify what the issue is? I have no doubt that you know, but some of the requirements may be in your head and not explicit on this forum, yet.
But I'm intrigued and would like to find out why a simple combination of "Module Grants + Revisioning + Workflow" wouldn't work for you... (maybe when we've sorted this out, we can publish our experience in another tutorial...?).

So to better understand what you need, can you please clarify some details...
You talk about "public" vs "private"... By this do you mean "visible to anonymous users" vs "visible to authenticated users (in some role)"?. If this is the case, then I don't think you need to assign the public/private categories, as this is already covered by the published/unpublished flag in combination with role permissions.... which would simplify things in that TAC(-Lite) would not be required...

You say: "without some access control, all the content is publicly visible".... As far as I know, content is only immediately visible publicly when the administrator ticked the "Published" box under Content management >> Content types >> edit >> "Workflow settings", for the content type in question. My recommendation in the context of publication workflows is to make sure "Published" is unticked, as it normally doesn't make sense to make content visible for all to see *before* it has been put through an approval (i.e. workflow) process. The primary goal of the Module Grants+Revisioning module pair is to deal properly with this situation, that is to handle access control of unpublished (as well as published) content.

I suggest that initially you disable the TAC-Lite, Content Access and Node Privacy By Roles modules for now, just so that whatever it is that's not working for you sticks out like a sore thumb. Then we can progress from there one step at a time, rather than throwing too many variables into the mix at once, as this make it hard to pinpoint what exactly isn't working for you.

Finally to answer one of your questions.... if Module Grants is enabled, then if content is UNpublished, the user (logged-in or not) must have (at least) the "view revisions" permissions to view that content.

Keen to hear how you go...

Rik

Hi Dennis,
Congratulations on getting the workflow part working!
By the way, what do you use the triggers for? As you know, triggers aren't strictly necessary for the separation of author and moderator responsibilities. Did you just use a trigger to enhance the moderator's user experience as outlined in the tutorial or for something more substantial?

In the context of drupal, "user categories" is a bit confusing, as "categories" is often associated with content taxonomies (aka vocabularies). "Users" have "roles".

So what I understand is you have:
o anonymous users (i.e. visitors to the website that don't log in)
o an Author role
o an Editor (=Moderator?) role
o a Registered Visitor role
o a Book Subscriber role

Are there more? Where do nurses, physicians and pharmacists differ in what they can/cannot do?

I note, that users may have multiple roles (this feature comes out of the Drupal box: User management >> Users >> edit).So some users starting in the Registered Visitors role, may at some point also gain the Book Subscriber role (if they pay you enough -- haha).

In terms of content, it appears you may need:
o a taxonomy/category/vocabulary that holds, at a minimum, a "book" and an "other" term, or
o a book content type

To start with the second point, you know that out of the box, Drupal allows you to assign edit and delete permissions per content type, e.g. per book content type. However, as explained in the tutorial(s), these permissions, if granted, override anything you may want to do with the Workflow or TAC-Lite modules, destroying all your good work regarding revisions and publication. So going down this path is unlikely to get you very far.

You may be able to do some more work with the workflow module.
Workflow's access grants apply per workflow/content type(s) combination. By that I mean that if you want access grants for some content type (say a custom "book content" type), to be different from all other content that participates in a workflow, then you could create a second workflow for this (book) content type. It would most likely be identical to the workflow for the other content types w.r.t its states and transitions, but as far as the view/edit/delete grants go, the "book content workflow" would allow the Book Subscriber role to view (published) "book content" whereas the Registered Visitor role would be denied all access.
Could be worth a try?

Alternatively, you could enhance the workflow you already have with a TAC-Lite approach.
I suggest you go through the "Revisioning with categorised content" again, but adapting it for your needs, i.e. changing some of the wording, e.g "department" vocabulary becomes "content category" (with terms "book" and "other" for starters). With the simple taxonomy in place, you can control for all roles (Authors, Book Authors, Registered Visitors, Book Subscribers) whether they're allowed to create (via the normal permissions), update and/or delete (via TAC-Lite) any piece of content and distinguish between "book" and "other" categories.

The Module Grants module will make sure that TAC-Lite and Workflow work together in harmony.

Hi Dennis,
Wow that's one hell of a workflow you've got there! A great test-case!

"All content types are tagged with drug/medical-related keywords that I've created with the Taxonomy module."

The plot thickens. If you extensively use taxonomies already, then I think TAC-Lite may be the way to go (in combination with your existing workflow). Like you say yourself: you want your access grants to depend not just on the type of content and its state, but also on taxonomy term set inside each individual piece of content.

Regarding node module options... "not an option for content that uses the publishing workflow; however, I can assign those permissions to types that don't use the workflow (e.g. the 'Page' content type).

Again, watch out with those pesky node module permissions. Content of type 'Page' may not participate in workflow, but if it has a taxonomy attached and you want to control access based on the taxonomy values (terms), then make sure you switch off the edit & delete permissions of the node module for the 'Page' content type or they'll supersede anything you try to do with the TAC-Lite or Workflow modules using that content type. "create" permissions are fine, as these aren't covered by TAC-Lite or Workflow and you do want certain roles to be able to create content.

If there are lots of roles AND lots of content types AND lots of states involved, then the Workflow-only approach will cause your set-up to explode (I think there might be a Cartesian product lurking in there somewhere).... I think you have started to feel some of that pain... In your case I would try the TAC-lite approach with a single workflow first. I don't know of a way to copy workflows in the Workflow module (but I'm not it's author or maintainer).
RE: performance.... I don't think that you'll notice any performance deterioration when using multiple workflows, it's not CPU intensive.

Your system of permissions and access grants is quite complex. Should you run into trouble and want to peek "under the bonnet" you can uncomment a couple of debug lines in the /sites/all/modules/module_grants/module_grants.module.
In the file module_grants.module there are 2 lines starting with

  //drupal_set_message("'$op' access= ...

Simply remove the leading slashes from these 2 lines.
Then click around your site as per usual and see what the debug messages tell you. In interpreting these messages note, that access codes greater than zero mean "access granted", while 'access=0' means "access denied".

I'm not saying that you shouldn't use the Content Access or Node Privicy By Rules modules, it's just that I have no experience with these, so can't comment. Plus I still have the feeling that your problem domain is by and large one that is targeted by the TAC(Lite), Workflow and Revisioning modules, so why introduce more modules, hence more interactions and likelihood of cross-module interference.
From its description CA seems more of a user-interface layer on top of Drupal's existing permission mechanisms, rather than being a permission mechanism itself (but I could well be wrong). By all means, once you feel you've got things under control, switch it on and see what it does for you. Same for NPBR. You're not on a path of no return, you can always uninstall what's not working for you.
I would go one module at a time though --- that's probably ambitious enough in your business domain, it has so many variables.

Good luck!

Another useful tool to analyse node access grants can be found in the Devel module. Under Site building >> Modules click "Devel node access", then under Site building >> Blocks configure "Devel node access by user" to be in, say, the right side-bar.
Finally, under User management >> Permissions switch it on for all "authenticated users".
Now visit a node and you'll find that a table on the right of your screen will list what access grants each user has to that node:

Access permissions by user

user               view  update     delete
blondie             yes   yes         no
admin               yes   yes         yes
arty                yes   no          no
moderator           yes   no          no

I suspect though, that the access grants shown this way follow the core Node module approach, which means that they won't apply to unpublished content and also may tell you the wrong thing when you have multiple node access modules installed (e.g. Workflow and TAC-Lite together) in combination with Module Grants. As explained on its project page, Module Grants ANDs the access rights together between node access modules, whereas the core approach is to OR these.

The patch mentioned in #453436: Add configurable setting that enforces explicit AND between multiple node access modules should greatly improve the way Module Grants works with other content access modules. It has been incorporated in Module Grants version 6.x-2.4