Workflow Finishing Proposal

By Lars Pind on 22 September 2000.

OpenACS Documentation : Workflow : Workflow Finishing Proposal


The Approach

The workflow package isn't very useful as a stand-alone package. It's intended to be deployed by some application. We won't fully understand the requirements for the workflow package until we have a pilot application to develop on top of workflow.

I propose that we designate such a pilot application and the resources to develop it alongside developing the workflow package. We should also agree that we have Brian avaiable to for business questions as we go along.

Feature List

This is the list of requirement/features that I've already identified. The time estimates are in ideal developer days, and very rough, since most of the features aren't very well defined yet. We'll close on the definitions in cooperation between marketing and development.

In addition to the list below, I'm expecting especially the end-user UI to get extended as we learn more about the real-life requirements.

No. Feature Description # Days Priority Risk Status Days used
10. Permissions Integrate with ACS Kernel permissions system. We need to define exactly what permissions are applicable. 3 High Med    
20. Email notifications The notifications package should be ready to go now. 1 High Low    
30. Static Assignments UI Fixed assignments for tasks can currently only be set in SQL directly. We need a simple UI for this. 1 Med Low Done 1
40. Handling Unassigned Task We need a way to handle unassigned tasks. Either a place where they can be picked up my an uber-user, have them automatically assigned to some person, and/or spamming some person. This ties in to deciding under what circumstances you're allowed to "pass the buck", i.e. assign a task to someone else, and if so, to whom you can assign it. This ties in to permissions, too. 3 High Med    
50. Simple Workflow Builder UI To design a simple workflow, the user won't have to know anything about the internals of the workflow engine. This UI has already been mostly done by Matthew. 3 High Med Done 5
60. Advanced Workflow Buidler UI Building advanced workflows will require knowledge of how the engine operates. This is a very straight-forward programming task, tough there may be a lot of work to do. 5 Med Med In progress  
70. Workflow Definition Versioning We need to store and manage several version of one workflow definitoin. This is necessary to let the manager redefine workflows without having to delete all the information we have on old cases. 7 Med High    
80. Workflow Summary UI We already have a very rudimentary UI for summarizing all the cases of a particular workflow, but it needs improvement to be really useful. 4 Med Low    
90. Workflow Debugging UI When managers start building advanced workflow and things don't behave as they expect, they'll need to have a UI for investigating what happened and why. 3 Low Low    
100. Workflow Maintaner UI This is related to the "static assignments UI". It's similar to APM, only for workflows. It would allow you to package up your workflow definition in some redistributable form, as well as install a workflow definition from such a file. 5 Low High    
110. Template User Pages Make sure all user pages are using the templating system. Due to the complexity of the pages, this is probably harder than one would expect. 2 Low Med    


lars@pinds.com
Last Modified: $Date: 2002/07/09 17:35:00 $