Forum OpenACS Q&A: Workflow "Rollback" Functionality?

Collapse
Posted by Jeff Wang on
Hello all,

I have been working with the workflow package on ACS 5 and have found it to be quite useful. I have a need for my users to be able to rollback to previous states in case they have made a mistake. Is there a way to do easily do this? The only way I can see is that you'd have to create a new transition that is always enabled to every state where rollback is necessary. I'd rather not clutter my fsm, with all these transitions though; is there any other way to do this? If not, is there any way to mark a transition as a special "rollback" transition?

Thanks for the help.

Regards,
Jeff

Collapse
Posted by Don Baccus on
Hmmm, that was a problem with the old Petri net based workflow package, too ... we dumped Petri nets in favor of FSMs but this particular problem still remains.

At the moment sticking in the explicit rollback transitions in the FSM is the only way to do this.

How far back do you want to go? The "start" state?

I suppose we could allow one to optionally mark a state as being "always enabled" ...

It's not nearly as bad with FSMs at least as it was with the Petri net implementation, though, in the latter case you have to make sure the right number of and combinations of tokens are generated and consumed as well as add all the transitions.

Collapse
Posted by Jeff Wang on
Ideally, we'd like to be able to rollback to any/every state, including the start state. I was thinking about updating the workflow package to create the rollback functionality by manually updating the current_state field in workflow::case::fsm and then updating with the global array that stores all the case info.. However, I am not that familiar with the internals of the workflow package and don't want to break something. I think I'll go with just creating the transitions... although it isn't elegant, it's only a minor inconvenience.

Thanks for the help!

Jeff

Collapse
Posted by Don Baccus on
I looked into workflow and and states have an optional "always_enabled_p" predicate that, if set true, causes that state to always be available.

If you're using the procs to get enabled actions to build a button-list or similar choice widget for user actions, the always_enabled_p states are returned along with the "properly defined" transition actions.

So this gives you an easy way to present the user a choice.

Now implementing the action properly is something else altogether and workflow will give you no help there. If the rollback action depends on the state you're rolling back to, then explicit transitions are probably the way to go...