Workflow Documentation

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.

Here's what we have to offer you today:

Package Developer's Guide to Workflow

This is for developers developing applications that should take advantage of the workflow service.

Functional Specification

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.

Version History

• 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.

Todo

• Internationalization.
• 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 pacakge.
• 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.