WorkflowEvent is a subclass of WikiEvent indicating a state change to a Workflow: started, running, waiting, completed, aborted. These correspond exactly to the states described in the Workflow class. All events are logged with priority INFO.

It defines the following event types:

  • workflow created : After Workflow instantiation.
  • workflow started : After the Workflow has been instantiated, but before it has been started using Workflow.start() method.
  • workflow running : After the Workflow has been started (or re-started) using the Workflow.start() method, but before it has finished processing all Steps.
  • workflow waiting : When the Workflow has temporarily paused, for example because of a pending Decision.
  • workflow completed : After the Workflow has finished processing all Steps, without errors.
  • workflow aborted : If a Step has elected to abort the Workflow.

Workflow is required for document control, checking/approving attachments, and filling and approving forms. Although strictly not a standard wiki function it is required in any project or enterprise CMS. Wiki does full document and version control of unstructured and generally unrestricted editing of content for the purpose of collaboration and in this context it is useful in an enterprise context. Wiki has the ability to restrict access. Workflow is just an additional sequential restriction on access to wiki collaboration. Integrating workflow into JSPWiki will be a huge benefit to JSPWiki users because it will fill in the small missing piece of functionality in enterprise application of JSPWiki.

An object subject to workflow is basically a template object which has several states each of which can have different access restrictions and which different users/groups can move to the next state (or possibly back to a previous state). Hence it isn't very different from standard wiki functions - it is just a different form of access control. Workflow objects should also be capable of setting different overall access restrictions depending on where it is viewed - for example you would want the lines in a drawing approval table to allow certain fields in each line to be updated in a "drawing entry" wiki, but you may want to view the table as read only when referred to in a "current drawings" wiki or list only approved drawings in the "approved drawings" wiki.

Although you could include workflow in JSPWiki by including a URL pointing to another application like Alfresco for example, the problem with this is that it leads to duplication of a lot of functionality, plus the need to log in twice, which is not really what people want. It is far better to include some basic workflow features in JSPWiki itself.

Should workflow be implemented by simply attaching a workflow object to another object? The workflow object would keep track of state and impose appropriate access restrictions on the object it is attached to, and show a visible indicator (tick button) which could be used by those who have access to do so to change the state. The object could also have a local flags which if set would prevent it's state and the content of the object it is attached to respectively from being changed if the object is viewed from another wiki, regardless of the access controls set in the other wiki.

TWiki implements a workflow implementation which may also be worth a look at.

--AnonymousCoward, 16-Sep-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-2) was last changed on 16-Sep-2007 20:23 by AnonymousCoward