See: Description
| Interface | Description |
|---|---|
| IWorkflowActionHandler |
Defines the methods by which a workflow action handler is called.
|
| IWorkflowManager |
Interface for Workflow Manager.
|
| 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. |
| 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 | 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 | Description |
|---|---|
| WorkflowException |
Workflow related exception.
|
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.LumisXP 12.2.0.200122 - Copyright © 2006–2020 Lumis EIP Tecnologia da Informação LTDA. All Rights Reserved.