Index: openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/design.html,v diff -u -r1.1 -r1.2 --- openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/design.html 13 Mar 2001 22:59:27 -0000 1.1 +++ openacs-4/contrib/obsolete-packages/acs-workflow/www/doc/design.html 19 Nov 2001 18:31:50 -0000 1.2 @@ -11,8 +11,8 @@
ACS Documentation : Workflow : Workflow Design Documentation
@@ -238,15 +238,12 @@
assignments by setting and querying a workflow
attribute. Conceptually, this is very nice, but with the current
implementation of workflow attributes, it doesn't allow multiple
-assignments to the same task, so we had to scrap that. Now we have a
-table, wf_case_assignments
, to hold this
-information. There's currently no way to have this queried for
-automatically as part of the workflow execution (i.e. one task is to
-assign the user to execute some other task), but we'll implement that
-as soon as it is clear how it should work (i.e. should there be a
-"base class" of parties to choose from? is this always one party, or
-does that need to be multiple parties as well?).
-
+assignments to the same task, so we had to scrap that.
+Since then we introduce the notion of roles to provide more flexibility
+in assignment of users to task. Roles are assigned to parties and
+they are associated with a case and/or task. This adds the functionality to
+group a set of task together for assignment (i.e. assign a role
+to a set of task)
We've decided to make the workflow engine have a PL/SQL-only
@@ -271,16 +268,16 @@
Some things, such as assignments, may be defined
cascadingly at several levels, such as statically for all
workflows, manually for each individual case, or programatically, by
-executing a callback that determines who to assign. For example, a
-task such as "send out check" would always be assigned to the billing
-department. A task such as "author article" would be assigned manually
-by the editor based on his knowledge of the skills of the individual
-authors. In the ticket-tracker, the task of fixing a problem would
-typically be assigned to a party based on who owns the corresponding
+executing a callback that determines who to assign based on roles.
+For example, a task such as "send out check" would always be assigned to
+the billing department. A task such as "author article" would be assigned
+manually by the editor based on his knowledge of the skills of the individual
+authors in "author" role. In the ticket-tracker, the task of fixing a problem
+ would typically be assigned to a party based on who owns the corresponding
project or feature area, and would be implemented by a callback from
-the workflow package into the ticket-tracker package.
+the workflow package into the ticket-tracker package. The callback would
+include the "module owner" role as its parameter.
-
@@ -656,12 +653,17 @@
Finally, the table
+VI. API
The API comes in two parts. There's one for manipulating
@@ -398,7 +395,7 @@
for each of the elements, i.e. places, transitions and arcs. There's
also a mapping table between transitions and workflow attributes,
saying which attributes should be the output of which transitions. And
-there's the now-obsololete wf_attribute_info
table that
+there's the now-obsololeted wf_attribute_info
table that
holds the wf_datatype
discussed above under design
tradeoffs.
@@ -419,9 +416,10 @@
Petri Net pretty closely. There's a table, wf_tasks
holding dynamic information corresponding to transitions, and one,
wf_tokens
, holding information about the tokens, which
-corresponds to dynamic information on places. Besides that, there are
-two tables, wf_case_assignments
and
-wf_case_deadlines
, holding case-level manual assignments
+corresponds to dynamic information on places.
+There is a wf_roles
that stores all roles for the
+workflow. Besides that, there are two tables, wf_case_assignments
+ and wf_case_deadlines
, holding case-level manual assignments
and deadlines. The assignments table is necessary because attributes
can't hold multiple values. The deadlines table isn't strictly
necessary, but it is an option in line with setting the deadline in
@@ -447,7 +445,7 @@
Workflow" section of the Developer's
Guide.
-Data Model Changes as per Nov 8, 2000
+Data Model Changes as per Nov 8, 2000 (Planned, but not implemented)
For permissions, the right solution seems to be to make at least
wf_workflows
, wf_cases
and
@@ -560,7 +558,6 @@
wf_attribute_info
should go away. We
don't need it any more, since it was only used for assignment
attributes, something that's gone now.
-
Note:
+The describe changes, as of Nov 8, are not implemented. These design changes
+will be factored into the next release of workflow. For the next release
+the most significant change is reimplementing the engine in Java. It will
+require changes the way guards, callbacks, attributes, and object transitions
+are handled. Don't worry as part of the next release we'll include,
+hopefully, a straight foward upgrade path.
-
VIII. User Interface
The user-interface falls in these separate parts:
@@ -715,25 +717,25 @@
standard format.
-IX. Configuration/Parameters
-There are currently no APM parameters for the workflow
-package. However, the workflow package, by design, does require
-customization by another package to be useful.
+There are two optional parameters under the APM,
+graphviz_dot_path and tmp_path. These parameters are required for
+the
+GraphVizv program used to generated the diagrams. Please read
+the installation guide for more details.
X. Future Improvements/Areas of Likely Change
@@ -754,9 +756,9 @@
XI. Authors
-
@@ -769,8 +771,13 @@
When?
By Whom?
-
+
+1.0
+ Minor updates about wf roles, parameters, and operational datamodel
+ 04/12/2001
+ Khy Huang (khy@arsdigita.com)
+
0.1
Creation
9/18/2000