You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The use case goes like this:
When I show an object, the view isn't editable and the user must click an Edit button to start the editing process. This sounds very simple except when you run check rules on object fetch.
If there are transformation rules, the object is changed as soon as it's fetched and needs to be saved. Now click Edit button. The Save button is enabled and when you want to navigate to another object, you have this nice alert box that asks confirmation, 'cause the object was changed and you didn't save it.
If there are business rules that depend on object lifetime, say when the object isn't new or it was created more than DD days ago, the are some warning or error icons that show on an object that isn't editable.
Our end user won't understand neither of the above situations.
The implementation is simple: there is a new state property IsReadOnly that is set to true when the object is fetched. No rules are checked on fetch. When you change the state property IsReadOnly to false, the rules are checked.
This feature must take into account Authorization rules. if the user can't edit the object, set IsReadOnly to false won't trigger rule checking. After setting IsReadOnly to false, you can check back on IsReadOnly to initiate or not the edit process.
Of course we could complicate the scenario a bit further. Suppose our rule system knows about the IsReadOnly and some rules won't run when it's set to true and others will - say urgent business rules that it must show whether the user can or can not do something about it. On this scenario we should check rules twice: on fecth and on edit demand.
The text was updated successfully, but these errors were encountered:
The use case goes like this:
When I show an object, the view isn't editable and the user must click an Edit button to start the editing process. This sounds very simple except when you run check rules on object fetch.
If there are transformation rules, the object is changed as soon as it's fetched and needs to be saved. Now click Edit button. The Save button is enabled and when you want to navigate to another object, you have this nice alert box that asks confirmation, 'cause the object was changed and you didn't save it.
If there are business rules that depend on object lifetime, say when the object isn't new or it was created more than DD days ago, the are some warning or error icons that show on an object that isn't editable.
Our end user won't understand neither of the above situations.
The implementation is simple: there is a new state property IsReadOnly that is set to true when the object is fetched. No rules are checked on fetch. When you change the state property IsReadOnly to false, the rules are checked.
This feature must take into account Authorization rules. if the user can't edit the object, set IsReadOnly to false won't trigger rule checking. After setting IsReadOnly to false, you can check back on IsReadOnly to initiate or not the edit process.
Of course we could complicate the scenario a bit further. Suppose our rule system knows about the IsReadOnly and some rules won't run when it's set to true and others will - say urgent business rules that it must show whether the user can or can not do something about it. On this scenario we should check rules twice: on fecth and on edit demand.
The text was updated successfully, but these errors were encountered: