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:
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.
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
.........
<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
However, Rules such as
ReplyDeletewhere "Internal/private_{asset_author}" role is mentioned cannot be used in mounted setups since in an mounted environment those {asset_author} is evaluated to be 'wso2.system.user'.
However, Rules such as
Delete"parameter name="STATE_RULE1:In-Review"
value="Internal/private_{asset_author}:+get,-add,-delete,-authorize"/"
where "Internal/private_{asset_author}" role is mentioned cannot be used in mounted setups since in an mounted environment those {asset_author} is evaluated to be 'wso2.system.user'.