I have a project object with a 1:1 (reference-both) relation with a planning object. I have a project dataview with a nested planning dataview. I have a before commit on project that performs checks on dates and blocks the commits on errors. It seems that even when there are errors preventing the project object from being committed, the planning (nested) object is committed. So for example: when a save on the project returns a blocking error indeed preventing the project from being committed the planning is still saved: When I cancel the project and then open it again the planning has changed. I would expect the committing of the planning object to be part of the project transaction. Question: Should it be part of the same transaction? So that a failed commit on project also means a failed commit on planning. In that case there must be a mistake in my setup. If not, should I use custom save and cancel buttons? If that is the case: Should I perform the checks from the save action? And if successful do a commit on the object without events? Without events because I also want the checks in the before commits on the objects but don't want them to be performed twice. Long question. Let me know if it is unclear.
asked
Frans Verschoor (FraternIT)
1 answers
2
Hi Frans,
If multiple dataviews are committed the do not run into the same transaction. If you want this behaviour you will need to use button with a microflow attached. To mirror the default save behaviour you need to do the following:
Create a custom button.
Attach a microflow.
Set form validation to All.
In the microflow, first try to commit the project object.
If you get errors the microflow will stop and you will return to the client window with validation messages.
Maybe it is even more flexible to validate the object yourself in the microflow and use the send validation activity to send custom validations to the client.
Only commit the planning object if the project object has been successfully committed.