Jspresso allows you to limit the access to parts of your application to users adhering to a specific role. Jspresso foresees to apply this type of authorization on about all elements of your application: properties, entities, (sub)views, actions,… The Jspresso Reference Guide fully explains this type of authorization.
We could call this type of authorization rules “static authorization”: A user is authorized to a part of the application depending on his role.
In some cases you might need a more dynamic type of authorization. Imagine for instance:
Employees can create and submit holiday requests. Once submitted for approval, the time sheet can no longer be altered.
Clearly here a more dynamic way of authorization is needed: Being authorized to edit a holiday request entity not only depends on the user’s role, but also on the state of the entity. Jspresso supports this kind of dynamic authorization with so-called “writabilityGates”. A writabilityGate is open or closed and can be attached to
Properties, entities and (sub)views: editable when the gate is open, read-only when the gate is closed
Actions: executable when the gate is open, the action can not be invoked when the gate is closed
A writabilityGate is bound to a model that opens and closes the gate. We give here an example of a writabilityGate that is open if the property “locked” is false and vice versa:
For instance, the above writabiligate could be included in an entity holidayRequest that is foreseen with an action “submit” that changes the property “locked” to true.
We invite you to do the test:
1)include the above snippet in model.xml in an entity that has a boolean propoerty called “locked” . All the views backed by this entity will be impacted.
2/ transfer the above snippet on an entity property descriptor instead of the whole entity. Now only the field (and table cells) backed by this property will have the behaviour (editable <-> read-only) as described above.
3/ now transfer the snippet from the model.xml to the view.xml. Include it in a view on the entity. Only this view will be impacted.
As you could observe, the effect of a writabilityGate will automatically propagate: For instance, if a property is closed for editing, then this will be the case in all views displaying this property. As usal in Jspresso, you must specify things only once!
Comments
Dynamic authorization with «writabilityGates»
Jspresso allows you to limit the access to parts of your application to users adhering to a specific role. Jspresso foresees to apply this type of authorization on about all elements of your application: properties, entities, (sub)views, actions,… The Jspresso Reference Guide fully explains this type of authorization.
We could call this type of authorization rules “static authorization”: A user is authorized to a part of the application depending on his role.
In some cases you might need a more dynamic type of authorization. Imagine for instance:
Employees can create and submit holiday requests. Once submitted for approval, the time sheet can no longer be altered.
Clearly here a more dynamic way of authorization is needed: Being authorized to edit a holiday request entity not only depends on the user’s role, but also on the state of the entity. Jspresso supports this kind of dynamic authorization with so-called “writabilityGates”. A writabilityGate is open or closed and can be attached to
A writabilityGate is bound to a model that opens and closes the gate. We give here an example of a writabilityGate that is open if the property “locked” is false and vice versa:
<property name="writabilityGates">
<list>
<bean class="org.jspresso.framework.binding.model.BooleanPropertyModelGate">
<property name="accessorFactory" ref="accessorFactory" />
<property name="booleanPropertyName" value="locked" />
<property name="openOnTrue" value="false" />
</bean>
</list>
</property>
For instance, the above writabiligate could be included in an entity holidayRequest that is foreseen with an action “submit” that changes the property “locked” to true.
We invite you to do the test:
1)include the above snippet in model.xml in an entity that has a boolean propoerty called “locked” . All the views backed by this entity will be impacted.
2/ transfer the above snippet on an entity property descriptor instead of the whole entity. Now only the field (and table cells) backed by this property will have the behaviour (editable <-> read-only) as described above.
3/ now transfer the snippet from the model.xml to the view.xml. Include it in a view on the entity. Only this view will be impacted.
As you could observe, the effect of a writabilityGate will automatically propagate: For instance, if a property is closed for editing, then this will be the case in all views displaying this property. As usal in Jspresso, you must specify things only once!