Package lumis.content.workflow
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 aarchivedState
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) $
-
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 toIWorkflowManager
.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.