I have an application in which their are two possible roles: “Requester” and “Approver”
When a requester puts in an order, the initial value of PENDING is set in the Approval Status field .
There are two other values: APPROVED and DENIED
I am trying to formulate and an access group or a role permission that does not allow the Requester role to modify the Approval Status field from PENDING. (An “Approver” doesn’t not have any such constraints)
The problem is I cannot set the approval status field to READ ONLY for the “Requester” role, because then the user will receive an error that the value cannot be set to NULL (it is not NULL, since ‘PENDING’ is set as an initial value)
Is there any best practice for handling this situation?
Initial Value is set for field, certain users should not be able to modify field from that value.
initially i just wanted to create an example app to show how it works. As it turns out, i did get the exact same error which you did (attached you’ll find the sample application anyways). Just try to create a order with the user credentials: username: “requester”, password: “requester”
The reason is that before the actual persistence, the attribute get’s wiped out, because of the security constraint (which is resonable). You can look at the code, which is responsible for this here: AttributeSecuritySupport.
As i’m not really sure about the solution to this, i will just append the example app and wait for a possible solution or explanation to this topic.
I would implement an action “approve/disapprove.” The property “approval status” should not be available for direct editing, but can be changed only from the action . So access to the action will be granted to the role approver .
PS
Usually wnen you approve an order it’s not just changing one of fields . It is a number of steps like notification of relevant users etc. So it a aways better to have a method at middleware that does it all. You can call it from Web UI now and later on if you need an iPhone/android UI you can invoke the same method to keep business logic consistent.
Please look at this topic, it contains a similar problem.
You have two options:
Turn off checking attributes on middleware by using the cuba.entityAttributePermissionChecking application property. In this case, visual components will still be disabled for read-only attributes, but programmatically set values will be stored.
Do not use attribute permissions in this case and use Specific permissions instead. I.e. you define a named permission, set it for a role, and in your controller code programmatically disable visual components if the permission is set to false.
That is a great suggestion, but overkill for this simple app. I like that idea however. Turning off checking attributes on middleware solved the issue for this specific problem. Thanks!