Page Comparison

Defines the class that is associated with the lifecycle.

org.wso2.jaggery.scxml.aspects.

JaggeryTravellingPermissionLifeCycle

org.wso2.jaggery.scxml.aspects.
JaggeryTravellingPermissionLifeCycle

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 elements that appear after this one contain subsequent elements are the actual SCXML configuration.

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

in the configuration.

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

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

• programmable executions for transitions.

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

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

ES allows you to define check items for each transition.

The permissions element defines permissions for that specified action and hold more than one child element which defines permissions. Under check items, the permissions element defines the users that have the capability of checking (check/uncheck) that check item. If a user does not have permissions to check a check item, then the management console will display that specific item in disabled mode. The idea behind this is to let the user know that there are some more check items in that state, but that he or she does not have permission to check them (so as to avoid user confusion).

This element is a child element of the permissions element and will define the roles that have permissions to do the specified action. Here, the attribute roles accepts a comma (",") separated list and these roles should be present in ES.

Defines the validations that need to be completed for each action. This element can contain one or more validation elements. Check Item Validators are one of many well-defined extension points supported by ES.

Validations are an important part of lifecycles. The validation element defines the event and the validation class that has to be invoked at runtime.

Defines the event for which this validation should be performed. This gives user the flexibility to define validations for each event. The user has the ability to define validations for check items, which makes it easy to validate different things at different levels.

The parameter elements are used to give parameters to the validation and execution classes. It is up to the user to define the name value pairs, and the parameter element has attributes to define these values. A validation element or an execution element can have more than one parameter element and it is up to the user code to handle this. The underline implementation of the DefaultLifeCycle class will pass all the parameters in a map object.

User defined value to identify the parameter.

ES lifecycle configuration has the ability to allow JavaScript functions to execute on both the server side and the client side. The js element defines the scripts that need to be executed for different events.

 Defines the transition action where this JavaScript function needs to be executed.

Defines the JavaScript function that needs to be executed on the client side.

Defines the name of the function which will be executed at a transition from one state to another.

Contains the actual JavaScript code segment. A user has the ability to define any code segment here.

ES supports scripting language.

This is the same as the console function and the only difference is that this element defines the scripts that need to be executed on the server side.

Defines the name of the function which will be executed at a transition from one state to another.

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

Defines the event for which this execution should be performed. This gives user the flexibility to define executions for each event.

The name attribute defines the name of the parameter and value attribute defines that the value hold by the parameter. This parameter element defined under the <execution> element.

A UI element is a mechanism to associate a user interface with a particular event during a given transition. This provides a convenient way for a user to pass input that would be utilized when performing a transition. Note that, for the value of href, it will not accept any external reference link for the value. It is required to provide a relative path in the carbon server as the value of href.

Defines the event for which this UI will be presented.

Defines the transitions of a state. In Governance Registry 4.1.1 onwards, users are allowed to define the transitions (the name and the target state) instead of using static transitions.

Previously, the configuration did not have a direct method of defining the transition event names or, most importantly, the target of the transition. There were only two transitions that were supported by default.

With the new, SCXML-based configuration model, any number of transitions from one state are supported. Also, this model has the capacity to define the target state of the transition and the name of the event as well.

Defines the transition event name, for example, to "Promote" or "Demote" or any name that the user specifies.

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:

• • Code Block
    <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.

  • Code Block
    <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.

  • Code Block
    <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. Any number of transitions for one lifecycle state are supported.

Defines the transition event name (e.g., Promote, Demote or any name that you wish to specify).

This event name is used in the forEvent to trigger a specific event, before this transition this going on.