Thursday, May 12, 2016

WSO2GREG Dynamically changing role permissions of artifacts

Some times there can be requirements, based on the lifecycle state of an asset, the set of permissions given for roles needs to be changed.

This post explains when assets move from one state to another in their lifecycle , how permission transition will take place. Lets define the permission transitions together with the registry resource permissions available at each state in the lifecycle is as follows:



          
Action
Current State
Next State
publisher
reviewer
everyone
promote
Initial
Created
+add
+delete
+authorize
+get


promote
Created
In-Review
-add
-delete
-authorize
+get 
+add
+authorize

promote
In-Review
Published
+add
+delete
+authorize
+get
 -add
-authorize
+get
demote
Published
Unpublished
+add
+authorize
...- get
promote
Unpublished
In-Review
+add
+authorize
...
+get

Once you define the permission transmissions then you can incorporate with transitionExecutions of the associated lifecycle along with "org.wso2.jaggery.scxml.generic.GenericExecutor" with STATE_RULES. This SampleLifeCycle is an example.


.........
<data name="transitionExecution">
    <execution forEvent="Promote" class="org.wso2.jaggery.scxml.generic.GenericExecutor">
        <parameter name="PERMISSION:get"
                   value="http://www.wso2.org/projects/registry/actions/get"/>
        <parameter name="PERMISSION:add"
                   value="http://www.wso2.org/projects/registry/actions/add"/>
        <parameter name="PERMISSION:delete"
                   value="http://www.wso2.org/projects/registry/actions/delete"/>
        <parameter name="PERMISSION:authorize" value="authorize"/>


        <parameter name="STATE_RULE1:In-Review"
                   value="Internal/publisher:+get,-add,-delete,-authorize"/>
        <parameter name="STATE_RULE2:In-Review"
                   value="Internal/reviewer:+get,+add,-delete,+authorize"/>
        <parameter name="STATE_RULE3:In-Review"
                   value="Internal/everyone:-get,-add,-delete,-authorize"/>
    </execution>
</data>
........
After performing Lifecycle state transitions, in the management console you can see the actual permissions for roles get changed at each state.


The correspondence between above permissions to actual permissions that we see associated to a asset is as below.

                       Permission Table                           Lifecycle         
Readget
Writeadd
Deletedelete
Authorizeauthorize
+Allow
-Deny

                ex:       +get == Read Allow 
                             -get == Read Deny
Read More

Monday, May 9, 2016

WSO2GREG-5.1.0 Store Extension Model


WSO2GREG-5.0.0 onwards, Store is build on top of WSO2 Enterprise Store code base. It has extension capabilities which are defined in https://docs.wso2.com/display/ES200/Working+with+the+ES+Extension+Model
There is a small deviation from above documentation when it is applied to Governance Center since some of the original Store code components mentioned in above documentation has been already overridden in Governance Center. However the pattern is similar as in the above documentation.
Below Image Explains the directory structure of expendable components for Governance Center-Store customizations.


  1. Asset extensions are available in this [GREG_HOME]/repository/deployment/server/jaggeryapps/store/extensions/assets/ location
  2. All the app extensions are organized in this folder [GREG_HOME]/repository/deployment/server/jaggeryapps/store/extensions/app/.
    1. Working with App extensions are described in https://docs.wso2.com/display/ES200/Introduction+to+App+Extensions
  3. You can add a new folder here to add a new app extension following the guide https://docs.wso2.com/display/ES200/Creating+the+Shell+of+an+App+Extension
  4. The default behaviour of asset types is defined here [GREG_HOME]/repository/deployment/server/jaggeryapps/store/extensions/assets/default
    1. https://docs.wso2.com/display/ES200/Introduction+to+Asset+Extensions
  5. All the default UI components are organized in this [GREG_HOME]/repository/deployment/server/jaggeryapps/store/themes/store folder.
  6. In GREG Store this [GREG_HOME]/repository/deployment/server/jaggeryapps/store/extensions/app/greg-store-defaults directory is used to override behaviour in 4. And 5. as a special case.
  7. We use the RXT shortname as defined in the definition. You may add a new asset extension with the singular name of RXT type to override the default behaviour 4, 5 and 6 by following the guide https://docs.wso2.com/display/ES200/Creating+the+Shell+of+an+Asset+Extension
    1. Here the priority will be given in the order of (7) >> (6) >> (5+4)
  8. This [GREG_HOME]/repository/deployment/server/jaggeryapps/store/extensions/assets/restservice is a sample of out of the box available asset extension.
Read More
Designed ByBlogger Templates