Package lumis.content.workflow

Provides workflow support for the content framework.

See:
Description

Interface Summary

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

Class Summary

ContentWorkflowMetaData	Value class for a content's workflow metadata.
WorkflowConfig	Contains the definition information for a workflow.
WorkflowController	Mediates content workflow operations from a process action handlers to IWorkflowManager.
WorkflowControllerXml	Deprecated. No longer used.
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.

Enum Summary

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

WorkflowException

Workflow related exception.

Package lumis.content.workflow Description

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