A String field can be calulcated to contain a specific String, based on a precondition. I have found in our application, that, if a precondition applies and the String field contains that desired string, when changing the document which should make no precondition apply anymore, the String field is not emptied, but continues to contain the value of the last precondition that applied.
The example:
If I have only the first two pre-conditions in my calculation, typically the first precondition fits and the field shows the value “Es wurde keine Voraufgabe oder Vorjahresaufgabe gefunden.” If I then alter the document such that neither the first nor second precondition applies, the String is not empty again. Instead, “Es wurde keine Voraufgabe oder Vorjahresaufgabe gefunden.” is still shown. I need to add the third precondition, so that there is always one of the now three preconditions that applies, so that the field always shows a String which fits the circumstances.
How can I make sure that a String field is emptied and removed from the document when no precondition applies any more, rather than forcing me to implement the third precondition?
Hi @jasper-silent-root
I imagine that your Computation Rule is functioning correctly in the Ad-hoc test and Form Model Preview. This is because clearing Field Values with a Computation Rule is fully supported in the Front-end.
Please have a look at this thread for more information about clearing Field Values in the Backend, How do I recompute an existing document in the backend? (solution).
We also created a Requirement Ticket, A12-16238, which has been completed for 2024.06-ext2. This means that when your project migrates, you will be able to clear fields when a Document is updated in the backend and no precondition applies.
Please note, you will need to set up Data Services correctly using:
mgmtp.a12.dataservices.documents.computation.enabledCleanupErrorAndNotComputedValue=true
We have upgraded to the 2024.06-ext3, I have set the application property in Data Services as you mentioned,
but it doesn’t work for me. I have an easier example of a calculation which only happens in the BE:
And yet, when my settings are such that when setting GemeinsamerEmpfang from some value to “SPIF_Anleger”, the value of WirkungBekanntgabe is not removed.
Hi @jasper-silent-root, could you please try cleanup-error-and-not-computed-value.enabled instead of enabledCleanupErrorAndNotComputedValue? It seems that the latter property is not interpreted at all.
Hi @jasper-silent-root, since the behavior between the client and the server should be per default the same, I have just created A12-17017 (Align the handling of computed fields between the client and the server).
Furthermore and for your information, I found a potential bug in the implementation of A12-16238 (ticket in which the server configuration cleanup-error-and-not-computed-value.enabled was introduced) and that’s why, I created A12S-5801 (When setting cleanup-error-and-not-computed-value.enabled to true, the computed fields with errors are ignored).
Hi @gildardo-cached-canyon, I haven’t tried your suggested solution yet. Am I however still supposed to use the suggestion in your first reply or are you saying my issue cannot currently be resolved without your mentioned bugfix?
@jasper-silent-root: Yes, please try what I suggested. The bug that I mentioned has to do with computed values which don’t comply with the field definition (e.g. max allowed value), normally a formal error should be reported for such value, but by enabling cleanup-error-and-not-computed-value.enabled DS (as far I saw) does not forward the correspoding error.
Hi @gildardo-cached-canyon, cleanup-error-and-not-computed-value.enabled does what I expected it to do.
Hi @gildardo-cached-canyon, (CC @markus-agile-fog, @constantin-cool-needle)
Though the property solved my issue, we needed to revert it. The property namely also contains the logic, that when a kernel validation is triggered (like trying to store a value for an enum which doesn’t exist in that enum list), all fields that do not have a precondition are put to null as well.
This kills our application, because we have about 20 calculations that do not have a precondition x 10 different tax types x ~4 different versions which all would need to be adapted with a senseless precondition, just to make sure that setting the property above doesn’t null them in case of a kernel error.
Is it possible to use the property while ignoring fields with preconditionless calculations? If that’s not possible currently, what would be the best way to achieve this?
Hi @jasper-silent-root, please be aware of the following information which does not depend on the server property mentioned above:
- A computation without precondition is always triggered.
- If the input data for the computation contains errors, no computation is triggered at all.
The standard behavior regarding the handling of computed values is:
- check input data
- compute all values which can be computed
- apply result to the document:
** clear “computed” fields whose value could not be computed or whose value was explicitely set to “”
** update field values which changed after the computation
** clear fields whith erroneous value (computed value which does not comply to the field definition, e.g. the value is greater as the defined maxValue)
If I understand correctly your situation, you have errors in the input data, that means, no computation is triggered and that’s why, all the computed fields are cleared regardless of having a precondition or not. Is this really the case?
Hi @gildardo-cached-canyon,
No, this is not the case.
We find that only when applying the property cleanup-error-and-not-computed-value.enabled in combination with invalid data nulls fields without a precondition.
Hi @jasper-silent-root
A12-16238 and the property you are using aligns the behavior in the frontend and backend so that the steps outlined by @gildardo-cached-canyon happen consistently.
This means that without the property cleanup-error-and-not-computed-value.enabled computed fields that could not be computed (no matching precondition) were not reset or cleared.
The property cleanup-error-and-not-computed-value.enabled “turns-on” this situation that you are seeing,
If you have a new requirement, please feel free to create a ticket so that it can be analysed fully.
Hi @malcolm-silver-ice,
Then I don’t understand why in our case, the clearing happened only for a small subset of fields. In this screenshot, you can see that only 5 fields were cleared (at the top), due to a kernel error (at the bottom).
We have way more fields that are being calculated, but they seem to not be cleared in this case. 
