Do Workflow permissions override Drupal core permissions?

Same issue here.

I faced the same problem.
Workaround: don't use the "Edit content in this state" setting of the workflow access module at all. Let the drupal core permissions determine who gets to edit a node.

What you describe seems, in general, to be the expected behaviour of workflow module.

#2 is not a workaround, its the actual correct configuration that will solve your problem: if you don't want workflow to handle a permission, don't give it on workflow and core will deal with it.

One other solution is to create one workflow to each of the node types.

Yet another solution is to create several states in the same workflow. E. g.: published news state, published entertainment state, reviewed news state, reviewed entertainment state. You will have to configure the initial transition from the creation state so that one role will only be allowed to go to published news state an the other to published entertainment state.

It also allows entertainment-author to create "news" content

No, the workflow module doesn't allow that. You can't set the roles who can create a node with workflow. You can only set transitions from the create state to other states, but «create state» has nothing to do with «create node permission». Create state is just the default state a node gets when its created.

Sending to active as I believe my permissions configuration does represent a conflict with core permissions.

I have employee profiles as a content type, and a role for employee_editors.
Employee_editors have the permission to "edit own employee_profile"

My workflow permissions allow for the role employee_editor to move an employee_profile from "active" -> "draft", along with the workflow permission to edit employee_profiles when they are in the "draft" state.

However, any employee_profile that I place into the "draft" state (as site admin) is then editable by the employee_editor role.

So, it is bypassing the "edit own employee_profile" permission and allowing an edit on ANY employee_profile.

Yes, the Workflow permissions override the drupal core's permission. The solutions mentioned at #2 or #3 works if we have 2 different content types which are associated with the same workflow.
You can try to use hook_node_access() to give an access denied . It will override the permissions assigned by the workflow module.

I believe I'm seeing the oppsosite issue from that which others have mentioned, but I'm not clear on a workaround.

I have one workflow (blog) applied to a single content type (blogpost). The workflow has three states: draft, review and live.

I have two roles, blog contributor and blog reviewer, set aside to deal with content creation and editing permissions for the content type and workflow.

I want contributors to be able to edit their own posts - but not the posts of others - when the posts are in the draft state, but not in the review or live states.

With core permission "node - edit own blogpost content" turned off, authors can't edit their posts while they're in draft state, even if that permission is checked on the workflow settings page.

However, with core permission "node - edit own blogpost content" turned on, authors can edit their own posts in draft, review and live states, even if the workflow settings say they're only allowed to edit posts in draft.

It seems as though the workflow settings permissions aren't doing anything here.

I have the same issue. (my content type was Story).

When I had "edit ANY Story content" was turned on, I actually had the workflow permissions working! (Users were able to edit node in the draft state, but not after node has changed to submitted state). But then I changed a permission and it wouldn't work when I changed it back. It seems to be a bug with Workflow, and what I've seen online, it seems quite common. I'm going to try uninstalling Workflow permissions and see if that works.

I am having exactly the same issue. The workflow module doesn't seem to be working correctly for limiting users edit abilities in states that are assigned. Did uninstalling and re-installing fix the issue?

In my experience, no. Once workflow permissions are "broken" the only way to fix it is to restore the database (I'm sure there's a way to fix it using SQL queries on specific tables/fields, but I'm not sure how).

It sounds like the past few comments here is a case of not understanding how the Workflow Access module works within in Drupal's Node Access system. Not your fault, just a documentation problem and considering the Workflow Access module is relatively new and this is to be expected. A required read should be the Drupal handbook page on the Drupal Node Access system. You can find that here http://drupal.org/node/270000

To summarize:
"Node access modules always GRANT access and never restrict it. (It is a whitelisting rather a blacklisting system.) If you use two node access modules and one grants access while another does not, access is granted. "

That means that the Workflow Access module DOES NOT RESTRICT PERMISSIONS. If there is an empty checkbox for a role editing a node in a specific state, that does not restrict the user from editing it if there is another "grant" somewhere allowing them to do that (like the "edit any content type x" permission in /admin/user/permissions).

this still looks wrong to me

i have a role called "pd translation" (rid = gid = 9). and a single user called pdtranslator in that role

the workflow perms are set for the state "Translation" to allow view/edit for this role: http://screencast.com/t/rNBWPbRiyz3G

the node is in this state: http://screencast.com/t/PyE0yIfeOLo4

and furthermore devel node access states the correct info: http://screencast.com/t/wEVCo57D it is saying that rid = 9 has been granted access due to the workflow_access module

PERFECT!!

except, pdtranslator has no view or edit access to this node.

hmm.. it seems as though this all works correctly as long as the node is published.. so in other words, if the node is published; but anon has no view access in whichever state the node is in; then they actually don't have view access.

this is all fine except for a couple things:

- doesn't this directly go against this:

"Node access modules always GRANT access and never restrict it. (It is a whitelisting rather a blacklisting system.) If you use two node access modules and one grants access while another does not, access is granted. "

- also, its a pain that i would then lose my watermark that signifies unpublished nodes; but, on the other hand it is nice that i don't need to set a triggered action to set node as published when i move it into the workflow state i have called "published"

Yup, a node set to unpublished will override Node Access, setting the view, edit, and delete grants for author only. In the future I hope Drupal will have just ONE state mechanism, but for now I hide the core Publish functionality and have it default to always published when using Workflow Access.

thanks.. glad to have it confirmed... that is what i have done.. :)

Betweenn #2 and #13 you should be covered.

Remember when working with permissions that Drupal permissions are additive not subtractive. If one module or permission says a user can do something, no other module will argue the matter (at least they're not supposed to).

Just to recap the input from the discussion above and my own investigation: in order for the workflow module to properly assign permissions on node edit, workflow has to be the ONLY module that grants permissions, so:
* do not use Drupal core permissions for edit and delete on content types you want a workflow to control. Grant permissions on creation though
* always have the content type that is controlled by workflow PUBLISHED - otherwise workflow permissions won't work properly
* in order to control if anonymous or other users can see content in particular state, use workflow to control those permissions. Then, even if a node is published, selected user roles won't have access to that content as per workflow settings