I've configured workflow_access such that, for instance, authors can not see or edit posts in the "review" state. Yet I can still log in as a regular user, create a post, set it to review, and then go back and edit or view it. The workflow_access module does not seem to be having any impact. I'm sure I've configured all the settings correctly.

Anybody else having this problem? Would love to get this working.

Thanks for a great module.

-Samantha

Comments

sammos’s picture

Component: Code » Documentation
Category: bug » support

Oops... I've got it sorted out now.

When using workflow_access, you must leave the "published" flag checked on all nodes and node types. You do not have to give users access to the "Administer nodes" if you do not wish. You do not use the Actions module to publish and unpublish nodes; they remain published all the time and you use the finer granularity of workflow_access alone to manage access to content in each state.

I had initially set all content to be unpublished from the creation to draft state, not realizing that workflow_access would not override the default Drupal behavior of not allowing those without "administer nodes" permission to view unpublished content.

I think some documentation about this in the readme file would be very useful. So I've moved this to support request for documentation.

syoumans’s picture

Thanks for posting this ... and following-up with your solution. It was helpful to me as well.

sammos’s picture

Sure. I should also note that this is probably only relevant for those working also with "actions" (which even comes with 2 default actions for publish and unpublish node! don't use those).

syoumans’s picture

Actually, now that I'm testing this out more, I'm noticing the following issue:

I've got an author - just a regular authenticated user - and an editor. Like your scenario, I don't want the author to be able to edit a node when it's in certain workflow states. So this author goes to view a node in one of these states. The author can see the Edit tab. When the author clicks the edit tab, the author is logged out of Drupal. When the author logs back in, the edit screen for the item comes up and the user can edit the item and save it.

So two things are happening: 1) the author is logged out of the system instead of denied access, and 2) the author can, eventually, edit the item if the login system is taking the user to the page they were trying to access at logout.

Any suggestions?

I'm using Drupal 5.1 with workflow-5.x-1.1 and workflow_fields-5.x-1.x-dev

sammos’s picture

hmmm that's odd with the logging out issue. i bet that might be another module, perhaps unrelated to workflow. Are you using anything that affects the login system or the 404 errors in any way?

i am using the same versions you are using except that i'm not using workflow_fields. I am using actions and the action fields module. I usually try turning modules off one at a time and retesting to find the actual module(s) that are causing the problem. I would also google as much as you can; perhaps it's already been reported somewhere.

Good luck!

zeitenflug’s picture

I'm using the newest workflow access module, but I can't prevent an author from editing his posts in review state. The node is published, the workflow options seem to be set right. Is there anything else I may have overlooked?

zeitenflug’s picture

I'd like to add, this is only a problem for editing rights. I can block viewing rights, i.e. if I say "authors are not allowed to view any article marked as being reviewed" authors get an access denied page. However, if I go straight to the edit page by adding /edit to the URL, authors can edit the article.

zeitenflug’s picture

Aaaaah, I think I have solved it. If you give authors "edit own content" rights, drupal ignores workflow_access settings. Could someone put this in the docs? I bet there are other drupal users out there who are nearly as ignorant as I am.

sammos’s picture

I have the same behavior with Drupal 5.x (dev) and workflow_access 5.x-1.1 -- removing "edit your own xxx" and "edit xxx" where "xxx" is the content type corrected the behavior.

shyamala’s picture

"When using workflow_access, you must leave the "published" flag checked on all nodes and node types. You do not have to give users access to the "Administer nodes" if you do not wish. You do not use the Actions module to publish and unpublish nodes; they remain published all the time and you use the finer granularity of workflow_access alone to manage access to content in each state." ---- Understand this is how workflow access works BUT I need my content published (ready for access on web/ search) only at the end of the workflow, so I need the access to work on unpublished nodes, any suggestions how to incorporate this???

Shyamala
Team Leader
www.netlinkindia.com

hillaryneaf’s picture

This may be the same question as above...

Articles in the draft state are not visible to users. So if one of my users is editing a page (it goes from final state to draft state), it is no longer visible to the rest of the users.

Ideally, I'd like to have the page remain online and visible to users until the new draft is published. Is this possible?

hillaryneaf’s picture

Component: Documentation » Miscellaneous

Is there some kind of versioning that's possible to allow the old page to stay up and when the new "version" is put up, it replaces it?

I can't have pages being pulled down during editing...

hillaryneaf’s picture

I found this module, which is exactly what I'm looking for:

http://drupal.org/project/revision_moderation

But it doesn't seem to work with Workflow :(

More info here: http://drupal.org/node/171210

gnassar’s picture

So, just to get this straight:

By default, workflow_access view settings override Drupal's built-in published/unpublished status.
By default, Drupal's built-in edit permissions override workflow_access edit settings.

Right?

silvanasono’s picture

Does anybody have any suggestion to solve this problem?

Thanks

arhak’s picture

Component: Miscellaneous » Documentation

you should open an issue for this issue.

arhak’s picture

So, just to get this straight:

By default, workflow_access view settings override Drupal's built-in published/unpublished status.
By default, Drupal's built-in edit permissions override workflow_access edit settings.

Right?

Right?!
I really think it MUST be documented !!

arhak’s picture

I remember I've read this already, but I think modules should document it too
How Node Access works: http://drupal.org/node/270000

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. This may be backwards from what some people would assume and is the reason why it is tricky to get involved with multiple node access modules. It is possible to use multiple node access modules in harmony however if for example they are applied to different content types or are giving out different grant types.

babbage’s picture

Title: Access not taking effect on workflow nodes » Workflow nodes must always be published for access controls to apply
Version: 5.x-1.1 » 6.x-1.x-dev

Encountered this issue setting up Workflow for the first time in Drupal 6.8. Yes, the solution is still that all nodes should be "published" in the system even before you wish them to be viewable—you can then fully control access to them using Workflow's options. If a node is marked as "unpublished" at any point it then becomes editable by the node author, regardless of ACL settings in the Workflow module...

Seems to me like it'd be better for this to be fixed properly, if it could be. However, it should at least be clear in "the documentation", as others have said above.

But does Workflow have documentation? There is not a link to any on the module page, and apart from the README.txt and the out of date Workflow-NG documentation I couldn't find sign of any. So perhaps a bigger support request would be "Workflow doesn't have documentation"?

pacotrade’s picture

Version: 6.x-1.x-dev » 5.x-2.3
Component: Documentation » Code
Assigned: Unassigned » pacotrade
Category: support » bug
Status: Active » Needs review

I have tested workflow_access with the same issue than sammos and others.

The problem is not due to workflow_access. it's the node_access function (core => node.module) that limit the node access control performed by workflow_access to only the published nodes.

Here is a patch who could be apply to node.module
first line modified add the reading of node_access permission to unpublished node.
second line modified limit permission reading when user is anonymous.

With this it work's fine !!!

\drupal\modules\node\node.module 2008-01-07 00:31:26.000000000 +-0100

@@ -2728,17 +2728,17 @@
if (!is_null($access)) {
return $access;
}

// If the module did not override the access rights, use those set in the
// node_access table.
- if ($op != 'create' && $node->nid && $node->status) {
+ if ($op != 'create' && $node->nid) {
$grants = array();
foreach (node_access_grants($op) as $realm => $gids) {
foreach ($gids as $gid) {
- $grants[] = "(gid = $gid AND realm = '$realm')";
+ if ($node->status || (!$node->status && $realm!='all')) {$grants[] = "(gid = $gid AND realm = '$realm')";}
}
}

$grants_sql = '';
if (count($grants)) {
$grants_sql = 'AND ('. implode(' OR ', $grants) .')';

PASCAL

jvandyk’s picture

Version: 5.x-2.3 » 6.x-1.x-dev
Component: Code » Documentation
Assigned: pacotrade » Unassigned
Category: bug » feature
Status: Needs review » Active

As explained in http://drupal.org/node/346021#comment-1175212 and above, this is the way Drupal core currently works. If you would like to work to change that, efforts should be focused on http://drupal.org/node/196922 and related issues, not here in the workflow module queue. pacotrade's core hack in #20 is not recommended as it changes the way Drupal core handles permissions and may affect other modules.

sammos in #1 and dbabbage in #19 have a request for documentation. That is a feature request for documentation. Please use this issue only to discuss that, or to provide documentation (say, as a patch to the README).

rameshrr’s picture

Hi,

I have the same problem, even when the content is in published state, my workflow access control get ignored. For example: I have three workflow states draft -> review -> publish, what I want is when the content is in draft state only the author of that content should be able to view, edit, and delete the node. When it moves to review state only the editor should be able to view, edit the node and the author should only be able to view it. When in publish state only the publisher should be able to view, edit and author and editor should only be able to view it. I have set the workflow access control to this permission but when I try it out the workflow permission gets ignored. I have been looking for a solution for weeks but not able to find any, any help in this matter will be appreciated. It seems that the core Drupal permission overrides workflow access control permissions.

Thanks

Leeteq’s picture

hillaryneaf’s picture

Revisioning module + Module Grants + Workflow is a great alternative. You don't have to give administer nodes access to users to publish content. And once content is published live it stays live and users can submit revisions against it and a publisher can then publish revisions when they would like to.

Here's a great step by step tutorial for it: http://drupal.org/node/408052

d.cox’s picture

#1 Thank you this has been driving me crazy for 2 days. Now it works that I am not change the publish settings with actions.

luco’s picture

thanks, @nektir - saved my life \o/

I think module grants should be a prerequisite for workflow_access to be enabled - until core behaves properly, of course.

would definitively save us some time and frustrations.

brisath’s picture

Subscribing

crea’s picture

Category: feature » support
Status: Active » Fixed

This is core bug-feature. Either use Module Grants module (which has it's own problems currently) or just give up.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

bsandor’s picture

Have a look at this:
http://drupal.org/node/300967