Allow the creation of "undo publication request" step

[sminnee]

Consider the following use-case:

• An author makes a change
• An author submits it for publication
• An author realises that there is one final change to make

In these situations a "make further edits" or "cancel publication request" action would be great. The workflow system is fairly configurable, but one thing it doesn't let you do is define an action that can be triggered by the original author even when the workflow has been assigned to someone else.

Adding "Who can perform this action?" as a dropdown to each action that defaults to "Current assignee" is part of this. However, what appears in the dropdown? The simplest would be to list all groups/users.

The problem I see with listing all groups/users in the system is that you need to create a whole new workflow for each set of users. It's one thing to say "a 2 step workflow lets Editors create content and Publishers publish it", but then if you have a separate section of site, e.g. Careers, with different editors and/or publishers you need to make an entirely new workflow such as "a 2 step workflow that lets 'Careers Editors' edit content and 'Careers Publishers' publish it".

This seems far from optimal but this limitation already exists in the system, so it shouldn't be solved merely for the feature described in this ticket.

[nyeholt]

Would the initiator have the ability to 'recall' a workflow at any time? Each instance already tracks the initiator, so my thinking is that the initial Workflow admin screen would be changed to

• show the list of all workflow instances this user is the initiator of
• show the list of all workflow instances this user is assigned to
• show the list of definitions (as currently shown)

The 'recall' action would basically do what the 'cancel' step does at the moment, which is to finalise the workflow instance and leave the content as it is, and send a notification to current assignees that it has been recalled. Sound good to you?

The second part of your post has previously been solved for one client by having a custom 'assign users' action that would look up the content tree for a 'ReviewerGroup' or 'PublisherGroup' relationship and use those as the assignees. It's not very generic, but re-usable.

I'd be hesitant to introduce a 'who can perform this' type of field to an action; that's the whole point of having the assignment action as a specific step.

[sminnee]

Would the initiator have the ability to 'recall' a workflow at any time?

Probably, but I'd expect that should be workflow configurable. You might have global actions and step-specific actions as a way of dealing with this. Or you could just make a "recall" action at every point.

I'd be hesitant to introduce a 'who can perform this' type of field to an action; that's the whole point of having the assignment action as a specific step.

It's a model that works 90% of the time, and an excellent default, but there are 10% of the remaining cases, such as this one. It's a request of whether you treat recalling a workflow as a hard-coded thing or as something configured. My concern with hard-coding it is that you would get further than further away from actually customisable workflow, although I can see that this is a tough judgement call to make. If you implemented my suggestion, the "assignee" would be "default actor" as opposed to the "only person who can do anything". It's similar to the way you choose who can edit the page at that time, I suppose.

The second part of your post has previously been solved for one client by having a custom 'assign users' action that would look up the content tree for a 'ReviewerGroup' or 'PublisherGroup' relationship and use those as the assignees. It's not very generic, but re-usable.

I picked this up again in point #18. We can probably do better than that, although the best solution might be to couple it with relevant core changes.

[nyeholt]

So what I'm feeling is that it's not so much the action that is of interest here but the actual transition from a 'pause and wait for user decision' workflow step to a 'cancel workflow' endpoint step, and making that transition triggerable by the initiator (or some other user - as per #18). At the moment transitions do have the concept of being valid, but there's never been a defined use-case around how this might work yet; perhaps this is?

From a workflow creator standpoint, they'd need to create a 'Recall workflow' transition from the 'decision' workflow action to the cancel workflow action, and mark that transition as being triggerable by the initiator.

From the initiator standpoint, they would see the same thing as other workflow assignees on the 'Workflow' screen of the relevant content, except their available choices would be restricted to whatever transitions they've been given access to (ie the 'Recall' transition).

[sminnee]

Here's the workflow that I'm using as my model: https://skitch.com/e-sminnee/esjx8/silverstripe-workflows

By "User decision workflow step" do you mean the "Progress workflow" step in that screenshot? If so, then yes, you're right.

If, however, you mean merely adding one more "are you sure?" step, then no: the editor should be able to recall the workflow at any time up until the publisher has actually published.

[sminnee]

PS: Feel free to Skype me if you think it would be more effective to discuss that way.

[nyeholt]

Yep, by decision workflow step I mean any step with more than one outbound transition (ie it requires a user to select the transition to take). Given single transition steps are all executed 'immediately' one after another, there'd be no chance to recall for the end user anyway :)