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$ $Date$

Interface Summary

Interface	Description
IWorkflowActionHandler	Defines the methods by which a workflow action handler is called.
IWorkflowManager	Interface for Workflow Manager.

Class Summary

Class	Description
ContentWorkflowMetaData	Value class for a content's workflow metadata.
WorkflowActionExecutedEvent	Event generated when a content's workflow action is executed.
WorkflowConfig	Contains the definition information for a workflow.
WorkflowController	Mediates content workflow operations from a process action handlers to IWorkflowManager.
WorkflowManager	The default implementation for IWorkflowManager.
WorkflowPermission	A workflow permission, that associates a principal with a role for a given service instance.
WorkflowRoleConfig	Value class for workflow role.
WorkflowStateConfig	Value class for content's workflow state information.
WorkflowStringResource	String resource for the workflow framework.
WorkflowTransitionConfig	A transition between two workflow states.
WorkflowUtilInternal	Utility class for workflow classes

Enum Summary

Enum	Description
StateScope	Enumeration of all available scopes for a state.
TransitionScope	Enumeration of all available scopes for a transition.
WorkflowTransitionConfig.WorkflowLockAction	Defines the possible actions that should be taken regarding lock in the ContentLocale.

Exception Summary

Exception	Description
WorkflowException	Workflow related exception.