WSO2GREG Dynamically changing role permissions of artifacts

By: Unknown on 1:56 PM

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
Read	get
Write	add
Delete	delete
Authorize	authorize
+	Allow
-	Deny

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

Read More

WSO2GREG-5.1.0 Store Extension Model

By: Unknown on 8:08 AM

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