Index: openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/requirements.html,v diff -u -r1.1 -r1.2 --- openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/requirements.html 13 Mar 2001 22:59:27 -0000 1.1 +++ openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/requirements.html 19 Nov 2001 18:31:50 -0000 1.2 @@ -9,8 +9,8 @@

Workflow Requirements

-By Lars Pind on November 8, 2000. - +By Lars Pind on November 8, 2000.
+By Khy Huang on April 13, 2001

ACS Documentation : Workflow : @@ -56,9 +56,10 @@

The process acts upon objects of a certain type. +
The process acts upon objects of a certain type. -
The process is the same for every objects of this type. +
The process is the same for every objects of this type. Currently +this feature is not supported.
For each instance of the object type, the process can be characterized as a series of possibly conditional and otherwise @@ -123,10 +124,6 @@ - - - -
III. System Overview
The workflow package consists of three separate parts. @@ -421,146 +418,23 @@ and the chairman must approve it.
-10.4.1 Explicit and Implicit Condition Routing The decision can -be made either as we're finishing the prior task, or as we execute one -of the two conditional tasks. The above example is one of explicit -conditional routing. An example of implicit conditional routing is -that we mail a form to the client, which the client must fill in and -return. If the user doesn't respond within a certain time-limit, we'll -do something different from when the user does respond. But the -decision needs to be made as late as possible, so we don't decide what -way to go until we receive the form or our patience runs out. - -

- +

10.4.1 Explicit and Implicit Condition Routing

- -

20.0 Permissions (NEW) -

- -Following is the complete list of permissions that I can think -would be necessary and reasonable. - -

- - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Privilege Task Case Process System Explanation
View task x x x x View the information about a task
Execute task x x x x Start/Finish/Cancel the task, and possibly do - assignment/attribute setting as part of executing the task. - If you have the execute priviledge, you additionally have the - option of backtracking and undoing any tasks that you have the - right to execute (although you can only undo backwards, so if you - don't have permission to undo the latest task done, you can't undo).
Assign task x x x x Assign or reassign users to tasks. On the task or case level, - it's manual assignments. On the process or system level, it additionally - includes static assignments.
Edit task x x x x Set time estimates and deadlines for tasks. On the task and - case levels, this means setting it for the case. If it's on the - process level, it additionalli includes the option to set time - estimates on the workflow level
Case overview N/A x x x View the whole case in one snapshot. Will allow you to see all - the process, and the whole history of the case in the light of - this process. On the process level, it additionally allows viewing - of the process performance overview page, including drilling down - into all the cases of this process.
Alter state N/A x x x Alter the state of the case, including back-tracking, editing - attribute values, and putting the case into any valid state.
Edit Process N/A N/A x x Define or edit the process definition itself, indluing - adding/editing/deleting transitions, places, arcs, guards, - callbacks, etc.
- -
- -

- -

30.0 Process Definition Versioning (NEW) -

- -We need to be able to keep multiple versions of a process -around. One of these will be the active version, which means -that it's the one that'll be used for new cases. - -

- -

30.1 Once cases exist of a specific version of a process, -that version can no longer be altered. But a new version can be -created, which will start out identical to the existing version, and -this version can then be altered as needed. - +The decision can be made either as we're finishing the prior task, or as we +execute one of the two conditional tasks. The above example is one of explicit +conditional routing. An example of Implicit conditioning, is a restaurant +owner purchases perishable goods, such as meat and vegatables. The food items +sit in a queue waiting to be processed into meals or wait for 15 days (meat +and vegatables tastes change after 15 days). If the task "wait for 15 days" + is completed, then the food item is thrown away. The routing is determined by +the first task to execute.

- +

- -

Tasks

40.0 Inputs
The item that the workflow is about will always be part of the input, @@ -589,7 +463,7 @@ takes time, so we must have a "start", "commit", "rollback" meachanism.
- +
70.1 There should be a date, such that, if the user has stared, but not committed or rolled back the task before that timeout date, the task is automatically rolled back and the task is created again. @@ -599,22 +473,23 @@
80.0 Assignments
-Tasks can be assigned to specific parties. +Tasks are not assigned directly to users, instead we associate roles +with a task. A role is granted to a single or a group of users. +Users belonging to that role have execute privileges on the task +associated with role.
-80.1
1. Static assignment: while defining the workflow
2. Manual assignment: assignment of tasks to users is part of the -workflow process, as in the user-scenario above. +workflow process, as in the user-scenario above. Only users with the +role associated with task are available for selection.
3. Programmatic assignment: The assignment is made automatically based on some condition, e.g. a category. It should be done with a call-back in the RDBMS layer, so another package that uses the workflow package can provide their own logic, without having to use the same webserver as the workflow package might. -
@@ -629,6 +504,9 @@
Each task can have a deadline, a date by which is must be performed. This is determined by a call-back as the task is created. +
+90.5 Completion time A task has an entry to estimate how long +it will take for completion.
@@ -660,27 +538,14 @@
When a new task arrives
When a task is finished. - -
Possibly also:
- - +
When a task gets unassigned
When a task is started
When a task is finished (committed)
When a task is canceled (rolled back)
When a task times out and is canceled. -
-
115.0 Callback repository (NEW) -
- -There should be a repository of callback routines which can be used -through the advanced process builder. They should include -documentation. - -
-
120.0 Automatic tasks
A task can be "automatic" in the sense, that it is only there for the @@ -692,17 +557,20 @@ useful for timeouts, e.g. when waiting for a client to return a form, we may cancel the case if we don't hear back within a month. The point in time is determined via a call-back. -
+
120.5 Message tasks +
A message from an external source can be passed to the task. The task +is executed upon receiving the message and all the criteria placed on +the message are satisfied. +
125.0 Commentability
The user can post a comment on a task at any time during the life-cycle of the case . The comments are shown to the users, so they can use them as a guidance in processing the case.
-

- +

Contexts

Static assignment -
The number of minutes estimated to complete the task - +
The side effect events that trigger a callback +
Roles associated with a task.

Note! It may or may not be the case that a context will always also be a subsite, in which case we don't need any -additional concept to model this situation. We'll need more -information from marketing to determine this. - +additional concept to model this situation.

- - -

VI.B Requirements: API

Controlling the Workflow Process

@@ -751,8 +613,10 @@

200.0 Start workflow

-Start a new instance of the workflow around an object, e.g. when a new -applicant signs up. +Start a new instance of the workflow around an object. Currently +it is not possible to have a callback in the kernel upon new +object creation. This requires programmically calling the +method to start a new case.

210.0 Cancel/Suspend/Resume workflow @@ -773,10 +637,11 @@

230.0 Workflow Attributes

-There must be a way to query workflow attributes, so conditions, -side-effects and other call-backs can use those in their code. -

- +Attributes for a process to use for branching and keeping state +properties. +

230.10 Add and Edit attributes attributes per case +

230.20 Access to those attributes values in the callback + procedures @@ -788,8 +653,6 @@ - -

VI.C Requirements: Web Interface for Interacting with the Workflow Process

310.0 Task information and management

See the user-scenario for a sample page. -

@@ -826,17 +688,16 @@

400.0 Simple Process Wizard - +
400.0 Simple Process Wizard

+Step by step directions for creating a new workflow process. +Do not expose process designer to more advance features such +as addition parallel routing.
- -
410.0 Advanced Process Builder - +
410.0 Advanced Process Builder
+Exposes all the glory details of each entity within the workflow.

- -

VII. Revision History

@@ -846,44 +707,44 @@ - - - - - + + + - + + + + + + - - - - + + + + - - - - - - + + + + - - - - - + + + + -

When?	By Whom?
0.1	Creation	8/10/2000	Lars Pind +	2.3	Minor edits	04/13/2001	Khy Huang
2.0	Added information on permissions and versioning.	11/8/2000	Lars Pind
	Reviewed	8/11/2000	John Prevost, Mark Thomas, and Pete Su	0.3	Reviewed, revised, and updated - conforms to requirements template.	8/22/2000	Bryan Quinn
0.2	Revised and updated	8/12/2000	Lars Pind
0.3	Reviewed, revised, and updated - conforms to requirements template.	8/22/2000	Bryan Quinn		Reviewed	8/11/2000	John Prevost, Mark Thomas, and Pete Su
2.0	Added information on permissions and versioning.	11/8/2000	Lars Pind	0.1	Creation	8/10/2000	Lars Pind