workflow view/edit/delete permissions for roles & states not working

I'm interested in having exactly same functionality: once the state is set to final "Released" state, author should be no more allowed to edit/delete the node. I'm using 6.x-1.0-rc3 and it also does not work there :-(

Doesn't work for me, either :-(. I would love to know the ETA for a fix.

subscribe

Escalating to critical.

* workflow_access settings are all OK but actual access is not as expected

* View access is denied to different roles on the same content type even with identical sid,rid and grant_view settings

* node_access permissions all OK

Many thanks!

R3

this is really critical. I thought it would work after all this configuration hassle, but as we tested today, it simply doesnt do what it should.

Is it working in the latest dev release?

hmm, so i researched ..

It all comes down to node_access where hook_access is invoked for the content-type's module. If this access callback returns something different than NULL, node_access will exit immediatly without checking grants, which is pretty rude.

We mainly care about editing/deleting nodes that are restricted to do so by a certain user in a certain workflow state, so the op we have to look for is "update" and "delete" in modules that implement hook_access if something doesnt work there. In my case, most of my types are just nodes (with cck) where "node_content_access" is invoked (since the module I use for the node-type is just "node"). Looking into that function (see D6 API) we find that the permissions to "edit any %type", "edit own %type" and "delete any %type", "delete own %type" are queried for a simple node. Just remove these node-permissions from your target roles and workflow will get its chance in node_access, because node_content_access is returning nothing (NULL) when these permissions are not set for the user. Works also for viewing, as long as the status is considered as TRUE ( == 1 is published I believe). Note: You'll always have access if you got "administer nodes" permissions.

Actually I do not know, why node_access returns immediatly when a proper hook_access has been found (and is returning something), makes not really sense to me. I mean, these node grants are meant to give other modules a chance to alter the rights, so maybe both grants should be merged somehow. The way it is now, the node-type's module can explicitely say "stop right here, I give damn about grants". -- so, uhmm .. yeah, its not workflow's fault ;)

As japanitrat has noted, Drupal's current behavior is to ask the module that has a hook_access() implementation for the node type whether or not access should be allowed. It is only if the module does not respond that the node_access system in invoked.

This is explained, along with a nice flowchart (IMO the most difficult in the book!) in "The Node Access Process" on page 161 of Pro Drupal Development, Second Edition.

In other words, this is not workflow's fault because it is not even being called by Drupal core.

To see attempts to redo the node access system in Drupal core, see http://drupal.org/node/196922

Content Access now includes actions and conditions for Rules and Workflow-ng. (as of #323985: Rules integration)

Another interesting solution is Node Access User Reference. This module moves access controls into the node form, enabling, for eg, access configurations based on the field's default value(s) using php_snippets or tokens.

Yes, this might not be workflow's fault.

But if I understand the code correctly the core node module will not allow any access hook to be activated when the node is unpublished, because of the check

if ($op != 'create' && $node->nid && $node->status) {
/* handle permissions */
}

in the node_access function, as $node->status flags "published"/"unpublished".

Implying, if I am correct in my understanding, that workflow permissions will apply only for published content?

@MartinPaulo: you'd probably get a better answer if you asked that in the Core issue queue.

But if I am correct, isn't the fact that workflow permissions will apply only to published content a workflow problem rather than a Core issue?

It already feels odd to me that this has been closed with a "by design" status when it seems to me that removing node-permissions from target roles in order to get the workflow permissions to kick in just flies in both face of common sense and practical use.

As you point out in #10, the core node_access() function is the one responsible for invoking Drupal's secondary node access system, of which workflow_access is a part. And yes, the if statement there does test for the published status of a node.

This issue is marked "by design" not because the current arrangement is the best thing since sliced bread, but because it is "by design of Drupal core" that access is handled this way. In other words, the best place to change this behavior and make it better is in the issue I pointed to in #8 and other related issues, not here in the workflow queue.

Does Drupal's permissions model check to see if content/nodes are published before applying access rules? If so, then I don't understand why it should be a criteria that an object is published before applying permissions. I'm having a tough time getting Workflow to work properly, and it seems it's this check that's at fault.

Should this check be removed from 6.x with a patch? What part of the access model is still dependent on having a node published before applying access rules. Might it be best if that dependency (whatever it might be) is addressed so that we can use the permission model on non-published content?

justinz, you are not the only one to think that. But once again, expressing your opinion of Drupal's permissions model in this issue does not help matters. Rather, read up on the attempts to actually fix this. Some starting points:

http://drupal.org/node/196922
http://drupal.org/node/286692
http://www.google.com/search?hl=en&q=unpublished+permissions+node+access...

I'm not experienced at drupal, yet I'm in a crunch to deliver an application in days. I've batted around Books, Workflow, and several other efforts that bill themselves as being frameworks geared toward content moderation, but none are secure in that respect. Referring me to drupal's Seventh major release under development doesn't help much either. I've read hundreds of threads on this subject, and this one being very close to the heart of the matter, and nearly one month since that last post, I felt it might be a good idea to revive this thread in hopes to force progress toward a 6.x patch.

So for now I've chosen to publish everything and hope I don't miss anything of Workflow's extensive settings. This is mostly there, and tho I have to somehow get rid of "Published ..." from view titles, it's nice that a users sees their public and unmoderated nodes in the same views without too much custom view-building.

Yes, nodes MUST be published for Workflow Access permissions to have any effect, this is a limitation of Drupal core, not the Workflow module, as discussed here: Workflow nodes must always be published for access controls to apply.

it seems to me that removing node-permissions from target roles in order to get the workflow permissions to kick in just flies in both face of common sense and practical use

I appreciate the confusion, this tripped me up when I was new to Drupal also. What is important to understand is that Drupal's permission system is ENTIRELY based on "Allow" permissions; there is no such thing as a "Deny" permission.

So if a user has "Edit Own Content" in the global permissions, they will ALWAYS be able to edit their own content. Period. Doesn't matter if another module comes along with more fine-grained control that the user is not granted; they already have the "carte blanche" permission granted at a higher level.

In other words, don't think of blank permission checkboxes as "deny"... they're not. They're simply the absence of "allow". This is a subtle but crucial difference.

What this means in practice, is that higher-level "general" permissions must be removed, if lower-level "granular" permissions are to make any difference.

@RdeBoer

I am glad someone had the know-how and time to program this module and share it with the community. For me, the power of the Workflow module would be wasted and rendered almost useless without your Grants module contribution.

I've installed it in order for moderators to access unpublished nodes in my worklflow and it works a treat with just one permission change.

Well done and thanks!