Workflow Coordination Central

OpenACS Documentation : Workflow : Coordination Central

Mini-Tasks and Work Plan

Must-haves

• 60. Email notifications from the engine. Stas has written a simple notification package: packages/notification (depends on packages/acs-util). Talk to Stas about how to use it.

• 200. A pilot application package to build on top of the workflow package. We can't really get everything right until that happens.

• 240. Integrate with permissions. Permissions applicable to workflows are: (a) administer a workflow definition, (b) view a workflow definition and summary, (c) administer cases for a workflow, (d) view cases for the workflow.

• 320. We must have a UI for setting the static (context-based) assignments, so a manager can install a workflow definition and then fit it with his own user-base.

• 350. We currently have a problem with unassigned tasks and manual task assignments. Manual task assignments used to use attributes, but this was changed, because attributes can only hold one value each. And there's currently no way to assign users to unassigned tasks.

• 360. Implement a function to check for soundness of the workflow-net: here's how.

Nice-to-haves

• 260. Allow users to add random single tasks to their work list. That would help adoption, and it would help users by keeping everything in one place.

• 290. Add the usual callback mechanisms for setting estimated_minutes for a specific task (including adding the column to wf_user_tasks), so the estimate can depend on conditions in the environment.

• 300. The act of setting attributes should be separate from the act of finishing the task. The user should be able to set the attributes incrementally, have the value stored for her, and the finish the task when she's ready.

• 310. We need to be able to generate better UI for setting outputs. Currently we only really know what to do with short strings and booleans. This borders to the problem of automatically generating forms from metadata.

• 330. In order to make distribution of workflow definitions easier, we should probably have the callbacks stored in the workflow definition and not in the context info, or perhaps in both places. This is a trivial change and one of the things that we probably won't finally decide on until we have a pilot application.

Bigger Tasks

• 800. Maintainer's Guide.
• 900. Advanced Workflow Builder's Guide.

People

Stuff that's done

• 50. Test all callbacks (guards, assignments, enable, fire, etc.). Use and modify the sql/sample-expenses.sql sample workflow as needed. (they seem to work pretty well)
• 70. Modify workflow-package to use Michael Yoon's PL/SQL conventions, i.e. arguments shouldn't be named "v_foo", but just foo.
• 80. Modify workflow-create and workflow-package, so workflow_key, transition_key, place_key, context_key, etc., are called just that (and not workflow, transition, place, context) throughout the model
• 90. Currently, the wf_user_tasks view doesn't actually traverse the parties hierarchy. It should, using org_member_map in some way, but I'm not sure how. Talk to Rafi (rhs@mit.edu) about this. group_distinct_member_map seems to be the trick.
• 100. Neither UI nor engine currently enforces that only the assigned users are allowed to perform actions on tasks. This check should be added, and it sounds reasonable to involve permissions to do this in one way or another (doesn't it?). (Depends on 90)
• 110. Add workflow attributes to the task page and actually set the values.
• 120. Figure out how to use the metadata capabilities of the core for workflow attributes.
• 130. Integrate workflow with acs-kernel. We want every row in wf_workflows to be an acs_object_type, and every row in wf_cases to be an acs_object of that type. Should we discard the varchar primary keys, then? The point of varchar primary keys was to make it easy to move a workflow definition from one ACS-installation to another, and to make it easy to write a SQL-script that'll create your workflow, without having to store all the generated primary keys in SQL*Plus variables.
• 140. Move the journal stuff into acs-kernel. Journals make sense for all objects. The journal is about keeping track of actions on the object.
• 150. Modify workflow-create and workflow-package to work with the journal table that's been moved into the core.
• 160. Modify callbacks to take one varchar2 parameter that can be set in the context or wherever you specify the name of the callback proc/func. How? The signature for guard_callback will be (case_id, workflow_key, transition_key, place_key, direction, custom_arg), where custom_arg is a varchar2. In wf_arcs where you specify the guard_callback function name, you also specify the value passed to the custom_arg parameter. That way, the same callback function can be reused for similar purposes, and we can provide a small library of standard supplied callbacks to perform standard things, e.g., a guard-callback attribute_true, which takes the name of an attribute as the custom_arg, or a sysdate_plus_x timeout-callback that takes a value to add to sysdate as the custom_arg.
• 170. Manual task assignments: there should be a way to say "this task involves naming the party that should be responsible for this task and that task". The way I propose to do it is to kill the wf_case_assignments table and make them attributes with a certain name that is set as usual. Same goes for manual case deadlines.
• 180. Make task.tcl actually look like the mock-up in the requirements doc.
• 190. Suspend/resume/cancel workflow.
• 210. Work deadlines into the UI somehow.
• 220. Tie case attribute values to journal id's again, so we can see what values were the output of each task.
• 230. Add comments to a case.
• 280. Remove start_place_key and end_place_key and make it 'reserved words', so we just look for a place named 'start' and a place named 'end'. That would get rid of the annoying cyclical dependencies. The worst thing about them is that it makes it harder to create workflows, because you have to (1) insert into wf_workflows, (2) insert into wf_places, and then (3) update wf_workflows.
• 270. Add a column to hold estimated execution time for a task, to aid the user in planning his work.
• 340. Clean up, remove hacks, restructure pages under www.
• 600. workflow-definition UI (see below)
• 700. workflow process overview UI (see below) - this work has already been started, see www/admin.tcl and related pages.
• 250. Starting and managing the DBMS_JOBS that are supposed to be run. This is fairly trivial, but since no-body are using the features right now, we figured we wouldn't start jobs in the database.