Workflow on Share

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com




Goals


The primary aim of this piece of work is to enable the Advanced Workflow functionality currently available on the Alfresco Explorer client to also be made available on Share.


Current Functionality


At present Share only has very limited workflow functionality compared with Alfresco Explorer. However, Share does provide two basic workflow process definitions, 'Adhoc Task' and 'Review and Approve'. Users are able to initiate these workflows, assign the associated task to a single user and set some properties (title, description and due date). A user can see a list of all the tasks assigned to him, he can view the content associated with that task and he can mark the task as done.


Required Additional Functionality


In order for the advanced workflow on Share to deliver the same capabilities that are currently available on Alfresco Explorer, the following features must be implemented:


  • Administrators must have the ability to deploy their own workflow process definitions onto Alfresco. These workflow process definitions should be fully accessible through the Share client.
  • Users must be able to add, edit or remove content on the workflow instance, both at the time of workflow instance creation and while processing tasks during workflow execution.
  • Multiple users and user groups must be assignable to tasks. Furthermore, different strategies should be made available for determining when a task is complete if assigned to multiple users. E.g. at least one user has completed task, all users completed task, percentage of users completed task, etc.
  • It must be possible to define and deploy workflow process definitions which specify more than one task.
  • A task must be able to have multiple transitions. For example, in a simple review process, the review task could have an 'Approve' transition and a 'Reject' transition. Selecting a different transition should result in the workflow instance proceeding down a different path.
  • It must be possible to associate properties with a task. These properties must be viewable and editable by the assignee of the task (and possibly other users too). The Share client should automatically generate the forms for viewing and editing properties using the task definitions. It must be possible to customise theese forms.

High-Level Design


The required functionality has already been implemented on the Explore client, so relatively little 'back end' work is required. The majority of the task will therefore be to expose the workflow service to the Share client through an API of some kind and to implement the various UI components on the Share client that will be required for viewing/editing at the various stages of workflow creation and execution.


Workflow Service REST API


Workflow already has Java API (WorkflowService.java) and a Javascript API (WorkflowManager.java). A new REST API will be layered on top of the existing Javascript API, implemented through Web Scripts. Many of Alfresco's services are exposed through REST API's, making them highly extensible and scalable.
See also: Workflow REST API


Task Assignment Component


A component should be provided to allow users to be assigned to tasks. This component needs to be able to handle single-user assignment, multi-user assignment, group assignment and fixed (non editable) user assignment as defined by the task definition.


Task Properties Component


A component is required to display and edit properties associated with tasks. This component should be automatically generated from the Task Definition and should be customisable (via XML configuration). This functionality is already provided for node properties by the Forms service. The Forms service will be extended to enable it to also handle task properties.


Package Data Component


A component should be provided that allows users to access content in the workflow 'package'. This should support content CRUD. Read-write access should be determined from the workflow process definition and the available options set appropriately.


'New Advanced Workflow' Wizard


Need a UI that incorporates the various components into a Wizard. In addition to the UI components noted above the wizard will also require a process definition selection component and a process instance properties component.


'Progress Task' Wizard


Need a UI that incorporates the above components and also has transition buttons to enable the user to progress the workflow to the next stage.


Implementation


Task Assignees and Properties


The task assignees and properties will both be represented by a form generated using the FormsService. In order to achieve this a new TaskFormProcessor must be implemented which will support form generation but not form persistance. Instead the properties and assignee information will be persisted directly through the WorkflowService (REST) API.

Since Tasks are represented as TypeDefinitions and have PropertyDefinitions (task properties) and AssociationDefinitions (task assignees) the TaskFormProcessor will probably share a lot of behaviour with the NodeFormProcessor and TypeFormProcessor. Therefore some effort will be made to extract this common behaviour into a shared class.


Road Map


Milestone 1


Due Date: 12th October 2009

Key Deliverables:


  • Implement a TaskFormProcessor which supports display of Workflow Task properties.
  • Allow properties changes/updates to be persisted through the FormService REST API.
  • Implement a TaskFormConfiguration which should properly format the Task Form.
  • Create a rough outline of the Workflow REST API.

Engineering Notes

Attachments

    Outcomes