What is the difference between ValueType SavedValue and ActualValue in Row level security settings?
When the user changes any values in the GUI, these values are provided to the rule. So the UI reacts immediately to the changes done by the user.
This supports mainly scenarios where you want to conditionally show/hide some input widgets depending on values entered.
When the user changes values in the GUI nothing happens until the record gets saved. The rule always gets the original version of the record how it was loaded from the database.
This supports the real row-level-security scenario where e.g. the user is allowed to edit the record. When changing a status the record is not immediately disabled because the status has not really been changed (saved) yet. So the user can continue editing. The rule always reacts to what is real (stored in the database).
I have the situation, where the user is allowed see all rows but only add new rows.
I tried many combinations with Allow/Deny incl. Actual/SavedValue, but not success.
Is it possible make such use case with row level security rules?
So basically the user is not allowed to
- Edit existing rows
- Delete existing rows
But he is able to add new row. After the row is saved he is not able to edit it anymore. Is that correct?
Yes, exactly, this is it.
What we do is to define a lookup which returns something from the row.
If the lookup returns a value, it means it has been stored in a database already.
If the lookup returns nothing, it means it is a new record.
Then you can set up a row-level-security rule which denies editing if the record has been stored.
Is the processing order depend only on level value or the ActualValue rules have bigger priority then SavedValue rules?
The priority is not different. This setting only changes the behavior.
ActualValue will cause the rule to be evaluated based on the value just entered by the user.
SavedValue on the other hand will only evaluate after the user saves the form. Until then it will use the original value loaded from the database. This is useful e.g. when you want to disallow editing after changing a state. But before the user saves data the state effectively is not changed so therefore you use the