By Lars Pind
The workflow package provides a service to keep track of a process
involving multiple people around some object. Workflow keeps track
of the process you wish to follow, of where you currently are in the
process (the current state), and who's supposed to do what.
Mockups of alternatives for
Package Developer's Guide to Workflow
This is for developers developing applications that should take advantage of
the workflow service.
This is the document we wrote before implementing workflow specifying
how we intended to implement the package then. It is inaccurate in a
number of places where reality forced us to make changes.
Fall 2003 Extensions
Adding actions as sub-workflows, automatic/timed actions, more conditions before actions are
enabled, dynamic outcome of actions, resolution codes.
1.0d4 Resolved conflicts with old acs-workflow package, so they install side by side. (May 11, 2003)
1.0d3 Added Tcl API workflow::case::delete ;
fixed bug in PL/SQL implementation of workflow_case.delete/workflow_case__delete ;
added @see to workflow::case::insert.
1.0d2 Completed package developer's guide. Added -action_id
switch to workflow::case::get_activity_html.
1.0d1 Bumped up the version number to 1.0 to reflect the
fact that this package is actually at a steady state and fully
useful as is. Also added a little API and cleaned up things a bit,
the kind of things you learn while writing the documentation.
0.2d2 First version released along with OpenACS 4.6.2.
Add API for modifying live workflows, including ensuring that the modifications are
always safe (i.e. you can't delete a state that's used.)
Add a user interface for defining workflows.
Add a user interface for monitoring workflows and bulk changing
the state of workflows.
Periodically notify people of their outstanding assigned actions.
Add a task list user interface, either as part of the Workflow package, or as a separate package.
Add support for petri nets and other models.
Add timing of actions, deadlines, and integrate those with calendar.
Application integration with certain states and actions. For
example, in bug-tracker, we treat the "Open" and "Closed" states
specially. We also treat the "Resolve" action specially. Should be
possible to define this link.
Add workflow variants, so you can ship your application with
multiple default implementations of the same workflow and let the
user choose between the available variants (e.g. simple approval
vs. multiple approval variants, choice of triage and Q&A steps in
the bug-tracker, etc.). This should probably be tied to some
concept of an 'application' as in the bullet above.