Lifecycle Configuration Definitions

Defines the class that is associated with the lifecycle.

org.wso2.jaggery.scxml.aspects.
JaggeryTravellingPermissionLifeCycle

literal - This option depicts that the lifecycle configurations are setup using the ES Management Console.

This is the element that contains the new, SCXML-based configuration. State Chart XML (SCXML) is an open standard that ES supports. Up to this point of the configuration, there can be only one of each of the elements described above. They all provide metadata about the lifecycle (name, class, and other information). The subsequent elements are the actual SCXML configuration.

http://www.w3.org/2005/07/scxml

Defines the initial state of the lifecycle. The initial state does not have to be the first state of the configuration. Furthermore, by changing the value of this attribute, you can easily modify the initial state and the flow of your lifecycle.

Defines the states of the lifecycle. A lifecycle can have multiple states and if needed, you can define more than one state element in the configuration.

Defines the name of the lifecycle state.

This element contains all the custom elements, which are defined in the lifecycle model. Based on the SCXML specification, you can define a data model to a lifecycle state and you can use this extension to define custom elements.

Custom data elements (according to the SCXML specification) serve to define check items and transition executions. This element describes the data of its child elements.

Defines the extension point (e.g., Transition Executors) that is used in the lifecycle.

You can define only one extension point of a kind, because the underlined implementation ignores multiple elements and takes only one into consideration.

• checkItems - If the user is defining check items as its child elements.
• transitionExecution - If the data element defines programmable executions for transitions.

These elements contain the check items for each state. There can be more than one of these elements.

Defines whether the check item is required for a specific transition. A check item may be needed for more than one event, in which case, you can provide a comma separated list for the forEvent attribute.

An executor is business logic that is executed once a state transition takes place in a lifecycle. The execution element defines the event and the execution class that is invoked at runtime.

Defines the event for which this execution is performed. This gives you the flexibility to define executions for each event.
The forEvent value is defined under the <transition> element using the event attribute. 

The name attribute defines the name of the parameter and value attribute defines the corresponding value of the parameter. This parameter element is defined under the <execution> element.

This attribute defines the name of the parameter. 

• If you use the org.wso2.jaggery.scxml.generic.GenericExecutor executor, it is mandatory to specify the following default permissions as it is needed for the ES permission model.
  • PERMISSION:get

  • PERMISSION:add

  • PERMISSION:delete

  • PERMISSION:authorize

• In addition, you can specify custom rules for specific user roles that are executed when various state transitions take place.

• ES permission model related values
  • PERMISSION:get

  • PERMISSION:add

  • PERMISSION:delete

  • PERMISSION:authorize

• If you use the org.wso2.jaggery.scxml.generic.GenericExecutor executor, it is mandatory to specify the following default permissions names together with their corresponding values as it is needed for the ES permission model.
  • PERMISSION:get

  • PERMISSION:add

  • PERMISSION:delete

  • PERMISSION:authorize

• In addition, you can specify custom rules for specific user roles that are executed when various state transitions take place. In each of these rules you can specify as to which permission is added or removed when the state transition takes place. Permissions are added and removed in the following manner:
  • + <PERMISSION>
For example,  + delete means that the delete permission is added when the lifecycle state transition occurs.
  • - <PERMISSION>
For example,  - delete means that the delete permission is removed when the lifecycle state transition occurs.  

 For example:

• • <parameter name="STATE_RULE1:Created" value="Internal/private_{asset_author}:+get,+add,+delete,+authorize" />

    This means that when the lifecycle state changes to Created, the get, add, delete and authorize permissions are added to the private_{asset_author} user permission.

  • <parameter name="STATE_RULE2:Created" value="Internal/reviewer:-get,-add,-delete,-authorize" />

    This means that when the lifecycle state changes to Created, the get, add, delete and authorize permissions are removed from the Internal/reviewer user permission.

  • <parameter name="STATE_RULE3:Created" value="Internal/everyone:-get,-add,-delete,-authorize" />

    This means that when the lifecycle state changes to Created, the get, add, delete and authorize permissions are removed from the Internal/everyone user permission.

• ES permission model related values

  • http://www.wso2.org/projects/registry/actions/get

  • http://www.wso2.org/projects/registry/actions/add

  • http://www.wso2.org/projects/registry/actions/delete

  • authorize

Defines the transitions, by specifying the name of the lifecycle state and the target lifecycle state, instead of using static transitions. Any number of transitions for one lifecycle state are supported.

Defines the transition event name, e.g., Promote, Demote or any name that the user specifies.