Package lumis.content.workflow

Provides workflow support for the content framework. The main entry point for the workflow API is IWorkflowManager, available in ContentManagerFactory.getWorkflowManager().

To define a custom workflow, create a directory inside the <lumisdata>/def structure, and in that directory create a workflowdefinition.xml file (refer to workflowdefinition.xsd for details on creating the workflow definition XML file). Inside the custom workflow's directory you may also create a strings directory with the strings resources for this custom workflow.

A workflow may contain one or more states. To allow the change of states, transitions must be defined. Each transition represents a directed navigation between two states. A comparison between the workflow and a directed graph can be made: the workflow's states would be the graph's vertices or nodes; and the workflow's transitions would be the graph's edges or lines.

States may be defined as being one of the following special state types:

  • start: This is the initial state of the workflow. New content will always start in this state (but they may perform a transition while being added, in this case their first persisted state may be other).
  • published: Only contents in states of this type are published.
  • archived: When a published content reaches its end of expiration date-time and a transition from its current state to a archivedState exists, that transition is automatically performed. Using this feature you can automatically organize contents that were expired while published.

One or more roles may be specified for a workflow. The roles are used to configure permissions to the workflow's states and transitions. You apply permission for a role to access contents in a state by configuring the permission in that state. To allow a role to perform a state change through a defined transition, configure the permission in that transition. There are two scopes of permissions:

  • assignedTo: The role has the corresponding permission only if the current principal assigned to the content is the user or one of the groups he is member of; or if the content has no principal assigned to it.
  • all: The role always has permission, independently of the principal assigned to the content.

Since:
4.0.0
Version:
$Revision: 7374 $ $Date: 2007-06-12 15:51:06 -0300 (Tue, 12 Jun 2007) $