I have workflow and workflow access enabled (I did have field access as well, but have found that to be overkill for my use and turned it off)
I've rebuilt permissions a few times, and the relevant setup I have is pictured in the attachements:

Basically, an editor can make changes up to the time it is "signed off" by a reviewer. After that, an editor should make no further changes.
should work ... but a user with only an editor role (nothing else) is still seeing the edit tab - and able to use it. That's not how it's supposed to work, right?

There may be another module interfering (I have several dozen), but no other access control ones I'd suspect on the site right now.

Where can I look to find out why this function is still available? I rebuilt the menus, rebuilt the node_access table. The node access table looks to me to have the right rules in it (role #5 editor cannot update that node)


Where do I look next? The node is an 'Event' FWIW, but I've been able to replicate with another Content Type also

CommentFileSizeAuthor
workflow-roles_table.png7.87 KBdman
workflow-node_access_table.png16.19 KBdman
workflow-can_still_edit.png22.65 KBdman
workflow-signed_off_permissions.png21.59 KBdman

Comments

dman’s picture

dman commented

kerberos’s picture

kerberos commented

Do you still have the "edit own/any XXX content" permission set on the permissions page (under User Management)? I think that overrides these permissions. If you have it unset in the bigger permissions, workflow should add the permission back in via the grants table.

We are struggling with a similar issue but not on edit but rather on the view part (where there are no corresponding user permissions you can uncheck).

-Daniel Chvatik
Adulmec

korneld’s picture

korneld commented
Priority: Normal » Critical

I got a similar problem. I got a couple of stages set up where only certain users should see a given page/story and should be invisible to anonymous users. I don't understand, it worked before when I first installed the module. Even when I unclick all checkboxes under "Roles who can view posts in this state", stuff is still visible to everyone.

The site is launching next week. It is absolutely ctitical that this bug gets fixed asap. My butt's on the line people! Help!

korneld’s picture

korneld commented

I did some more digging and found out that there are issues now across the board.

I am having a hard time even with workflow permissions. I can grant a role that hasn't had this type of access before (anonymous), but I can't seem to be able to take it away from roles who had this permission before. However, I can still take it away from the anonymous user. I get the same results if I edit the info directly in the database.

Can it be that something is being overridden somewhere. I have cleared both my Drupal cache and my browser's.

mas160’s picture

mas160 commented

Same issue as dman. Enabling "edit own/any XXX content" Workflow rules don't care (edit is still permitted to roles supposed don't have this privilege by the WF permission rules); disabling them no editing is allowed, also in the node WF state which is supposed to permit edit.
In other words: permission in Workflow seem not to be effective.
For my site (an intranet documentation appliance) this is a critical feature, and I have to go online in a month....

jchatard’s picture

jchatard commented
Title: Isn't workflow access supposed to hide the edit button? » Workflow Access grants not always respected
Component: User interface » Code
Category: support » bug

Hi all,
i had similar issues. So I just started to digg into it.

And I think I found the problem.
 
First, I needed to uncheck the "edit own xxx", because it let node's author edit access in the whole node lifecycle, which I didn't want. 
Second, I think there is a bug, or at least something I still do not understand in D6 node.module node_access() function. On line 2037 a test case is made with node status. 

That test case is slightly different in D7 same function. So I removed the "&& !$node->status" from the if statment, and for now everything "seems" to work properly. 

This extra condition prevent workflow defined grants from applying. So I would say, but we definitly need more on this, that this could be a node.module issue. And maybe not a workflow access one. 

I'd appreciate some feedbacks on this guys. 

Thank you,
Jeremy

nota: remember that defined drupal core permission is "stronger" than a workflow one. So giving a permission with "edit any xxx" could lead to headache!

dman’s picture

dman commented

When I was testing this, I'm pretty sure the 'editor' role I was testing with was not the owner of the node. Although it's good to know that the drupal permission to 'edit own content' would have trumped any workflow permissions.
If that is really the case, then I guess the workflow I want is impossible?
Or to I remove the general permission to edit own content, and then give it back via workflow? Hm.

In my case, it all was too difficult, so I just opened up the rights and gave the users a verbal warning about what not to do. :-/

jchatard’s picture

jchatard commented

I have report an issue on Drupal project : #542788: node_access() prevent modules from applying grants on $node->status == 0

Jérémy

Bastlynn’s picture

Bastlynn commented
Status: Active » Closed (won't fix)

Since this request is over 2 years old, I'm going to assume a solution was found or you've moved on. If not, please get updated to the latest versions of all modules and make a request for it against Drupal 7 and I'll be glad to take a look at it.