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 an 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 gates. A gate is open or closed and can be associated to
Every gate refers to a so-called model that determines if the gate is open or closed. Jspresso comes with 2 predefined types of models:
We give here an example of a writabilityGate that is open if the enumeration property state has the value "created" and hence will be closed for other state values (f.i. "submitted"):
<property name="writabilityGates">
<list>
<bean class="org.jspresso.framework.security.GrantedRolesGate">
<property name="grantedRoles">
<list>
<value>Employee</value>
</list>
</property>
</bean>
<bean class="org.jspresso.framework.binding.model.EnumerationPropertyModelGate">
<property ref="accessorFactory" name="accessorFactory" />
<property name="propertyName" value="state" />
<property value="true" name="openOnTrue" />
<property name="openingValues">
<list>
<value>created</value>
</list>
</property>
</bean>
</list>
</property>
For instance, the above writabiligate could be included in an entity holidayRequest provided with an action “submit” that sets its property “state” from "created" to "submitted". Conclusion: The above writabilitygate specifies that only Employees are allowed to edit an holiday request, and only for requests in the state "created".
We invite you to do the test:
1)include the above snippet in model.xml in an entity that has an enumeration property called “state”. Alter the value of "state" and observe the impact. 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 the 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!