Closed (works as designed)
Project:
Workflow
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
28 Sep 2006 at 10:25 UTC
Updated:
8 Feb 2013 at 13:23 UTC
Jump to comment: Most recent file
Comments
Comment #1
jeff h commentedMy project is really going to need this... is anyone interested in coding it for me (let me know how many $$)?
Comment #2
MrTaco commentedthe node_perm module and atleast one other, already purport to be able to change the editability of a node (for a given role) when certain workflow state transitions occur on that node
personally, i have tried node_perm and it did not work (i think it conflicted with another permissions module i use), but i think you should give them a try
Comment #3
RobRoy commentedThis patch is for 4.7.x and includes some basic whitespace cleanup and a few comment changes next to code I modified. I can roll one for HEAD once I get some reviews on this.
Here is the use case Jeff H is talking about:
So we need to be able to FORCE a node to a workflow state just like we force (creation) -> the next available state. This patch covers that.
NOTE: You now must explicitly give an author/role X permission to go from State X -> State X. If a node is in State X and the only allowed transition for that user is State X -> State Y, upon saving the node it will trigger a workflow transition from X to Y. So if you want to do something like Jeff H does above, don't allow X -> X for a specific role, only allow X -> Y in the edit workflow transition grid.
We might want to include an workflow_update_5() to auto-check the author boxes for all State X -> State X transitions for people who are upgrading. Thoughts?
John, you've built a kick ass module! This definitely needs some testing as since maybe I'm missing something. :)
Comment #4
RobRoy commentedMarked http://drupal.org/node/55470 a dupe.
Comment #5
bdragon commentedI rolled back the whitespace changes to reduce conflicts and updated the patch to DRUPAL-5.
Hopefully I didn't miss anything.
Comment #6
udvranto commentedThis does not work. I tried commenting return in function workflow_execute_transition as shown in the code. But this causes stack overflow. Any solution?
[code]
function workflow_execute_transition($node, $sid, $comment = NULL) {
$old_sid = workflow_node_current_state($node);
if ($old_sid == $sid) { // stop if not going to a different state
// Write comment into history though.
if ($comment && !$node->_workflow_scheduled_comment) {
$node->workflow_stamp = time();
db_query("UPDATE {workflow_node} SET stamp = %d WHERE nid = %d", $node->workflow_stamp, $node->nid);
_workflow_write_history($node, $sid, $comment);
}
// we dont want to skip same stats
// return;
}
[/code]
Comment #7
udvranto commentedI tried to apply this patch for same state to same state workflow transition. The actions do not get applied during same state transitions! I tried commenting return statement in the function workflow_execute_transition as shown below. This causes the actions for same state transition to be applied but also causes stack overflow on new posts.
I tried the other patch. But this is the one I want as a solution for my problem.
Comment #8
udvranto commentedWhen a new node is created workflow_nodeapi is called with $op=="insert". After this actions get applied which in turns calls node_save and workflow_nodeapi with $op=="update". A recursive loop is avoided with a check on transition state. This is same for node edit as well.
If I do the following in workflow.module function workflow_nodeapi
and comment the following code in function workflow_execute_transition
then no transition check is used and new node creation falls into a recursive loop causing a stack overflow. But the edit works somehow. Now the problem is how to avoid the recursive callback?
Comment #9
udvranto commentedThis is what I am doing now in workflow_nodeapi function
In function workflow_execute_transition
Now I am getting "This content has been modified by another user, changes cannot be saved." Any idea?
Comment #10
udvranto commentedI believe I have a solution now. Along with the patch submitted by RobRoy in comment 3, you will need to replace the following function
Comment #11
udvranto commentedI forgot to describe the problem I was having. I was trying to solve the problem I described here. I needed actions in same-same transitions. Thats what I tried to do here. IMO, having same state transitions give more flexibility and should be added into the core.
Comment #12
gemini commentedI applied the patch replace the function, but then I got "This content has been modified by another user, changes cannot be saved." And now the workflow block does not appear of the user in the node edit. Any ideas?
Comment #13
gemini commentedOk, I tried it again and the patch in the message 3 by RobRoy worked. I guess I overwritten the wrong function. Thanks!
Comment #14
kirby commentedSorry, but I don't get the whole discussion.
So is it possible to make transition from Current State to Current State optional with Drupal 5.5 ?
Which patch should I use and are there any modification I have to make by myself (in file workflow.module or in the database) ?
Thank you
Comment #15
JacobSingh commentedThis doesn't look complete to me, and to be honest, I'm also a little confused as to what's going on.
Is the intention that:
We provide workflow state change access params so that the matrix allows you to specify which roles can transition between x and x, not just x and y?
For instance,
only editors can go from approved to approved, other users can only go from approved to "in moderation".
Is that the goal?
If so, whomever is working on this, can you specify what you are changing (from a front-end perspective) and provide a patch which can be applied to the DRUPAL-5 tag?
Best,
Jacob
Comment #16
bdragon commentedYeah, that's the sort of thing I've been using my patch in #5 for.
Comment #17
bdragon commentedHere's a patch against current DRUPAL-5.
The idea is to allow "forcing" content out of a state if the editor doesn't have permission to stay in the current state.
I know the patch itself seems a bit odd, but it's worked so far for me...
Thoughts?
Comment #18
ntt commentedsubscribing
Comment #19
chansion.vc commentedHow about D6 ?
Comment #20
Bastlynn commentedHi,
With the release of Drupal 7, Drupal 5 is no longer receiving security updates, reviews, or development from many contributed modules. Since 5 is now considered a depreciated version, you really should seriously look into upgrading to Drupal 6 or 7. The newer versions of Drupal work better, have more support, and will be safer (literally! security patches!) for your website. We are currently working on a new release for Workflow to Drupal 7. In light of that, further support for Drupal 5 issues is infeasible at the moment. Please consider upgrading to Drupal 6 or 7 in the near future - you'll be glad you did.
- Bastlynn
Comment #21
greenskin commentedHow can I do this in the 7.x version?
Comment #22
nancydruI would think you could set up a rule to fire on "After updating existing content." In the rule you can check if the node has any forbidden states and change the state.
The Workflow Access module (included) will disallow editing of nodes in certain states. I would think that stopping the problem before it happens would be a better solution.
Comment #23
greenskin commentedMy issue is I want an author to still be able to edit a piece of content but not have approval to change states, an editor would do that. But I want when an author edits a node in the final state it to be moved back to a lower state. The "Set workflow state for content" rules action appears to still check if the user has permission to make the transition. I want to force the transition, not simply allow the author to move it back. Your thoughts? Thanks!
Comment #24
nancydru@greenskin, that is a duplicate of #1691870: Workflow checks permissions even when state change is coming from rules.