Right now, when an object is sent back from the client to the server, only the id and the fields filled by the user are sent back. This is in order to limit security risk of data being tampered on the client side.
However, it causes issues for cases where draft data is pre-filled on the server , then sent to the client for completion, then sent back to the server.
The solution in this ticket will not challenge the following principles of Open Lowcode. No data stored for sessions on the server memory (to keep architecture simple and scalable).
Therefore, the solution proposed is to have an option where, in very limited cases, all the data on objects sent to the client is sent back to the server.
When using this option, actions at the receiving end should take all measures necessary to avoid security / data tempering risk. At minimum, user having done the modification should be recorded.
Right now, when an object is sent back from the client to the server, only the id and the fields filled by the user are sent back. This is in order to limit security risk of data being tampered on the client side.
However, it causes issues for cases where draft data is pre-filled on the server , then sent to the client for completion, then sent back to the server.
The solution in this ticket will not challenge the following principles of Open Lowcode. No data stored for sessions on the server memory (to keep architecture simple and scalable).
Therefore, the solution proposed is to have an option where, in very limited cases, all the data on objects sent to the client is sent back to the server.
When using this option, actions at the receiving end should take all measures necessary to avoid security / data tempering risk. At minimum, user having done the modification should be recorded.