Hi @raiko-static-field,
with the detailed structure of your DM, I understand the situation and can give an explanation. Thanks for the information, that helped me a lot (@malcolm-silver-ice: thank you for the model and data, that helped me as well).
To understand this situation, there is something I have to explain beforehand:
- Out of a computation rule in a DM, computation code is generated, but also validation code. In the latter case, the a simplified form of the generated validation rule would be as follows:
FilledField(<computedField<) and <common precondition> and <precondition 1> and [<computedField>] != <computed value 1>.
- In the method
DefaultDocumentService#computeAndValidateDocument, the computation is executed, the computed values are added to the document (if not formal errors are present) and last but not least, the validation of the modified document is executed.
For the second data set, we can expect the following focusing on the computations ComputationActivated and ComputationActivatedLabel:
“Computation phase”
ComputationActivated:
a. Precondition 1 is not met since Configuration/ActivePreset is not filled.
b. Precondition 2 is not met as well since ActivatedInput is not filled.
c. This means that Activated is not computed at all.ComputationActivatedLabel: This computation takes the result from the last computation into account.
a. Precondition 1 and 2 are not met since Activated is not filled (it could not be computed)
b. Precondition 3 is met and ActivatedLabel is computed to “none”
“Apply phase” (server-side)
In the A12 version 2023.06 only actually computed values are added to the document, this means, Activated is not changed in the original document, as you observed.
In the A12 version 2024.06-ext2, the DS configuration mgmtp.a12.dataservices.documents.computation.cleanup-error-and-not-computed-value.enabled was introduced to be able to have the following behavior: all field instances of a computed field are cleared (set to null) and afterwards all actually computed values are added to the document. The latter behavior is from my point of view the way how a computation result should be applied to a document.
“Validation phase”
- Rule generated from
ComputationActivated:
FieldFilled(Activated) And (
(
FieldFilled(Configuration/ActivePreset) And [Configuration/ActivePreset] == True
And [Activated] != [ActivatedPreset]
) OR (
FieldFilled(ActivatedInput) And (FieldNotFilled(Configuration/ActivePreset) Or [Configuration/ActivePreset] == False)
And [Activated] != [ActivatedInput]
)
)
a. FieldFilled(Activated) → true
b. FieldFilled(Configuration/ActivePreset) And [Configuration/ActivePreset] == True And [Activated] != [ActivatedPreset] → false since Configuration/ActivePreset is not filled
c. Because of the OR the next subcondition must be evaluated
d. FieldFilled(ActivatedInput) And (FieldNotFilled(Configuration/ActivePreset) Or [Configuration/ActivePreset] == False) And [Activated] != [ActivatedInput] → false since ActivatedInput is not filled
f. This rules does fire (does not produce any error)
- Rule generated from
ComputationActivatedLabel:
FieldFilled(ActivatedLabel) And
(
(
[Configuration/Active] == True and FieldFilled(Activated) and [Activated] == "TRUE"
And [ActivatedLabel] != "true"
) OR (
[Configuration/Active] == True and FieldFilled(Activated) and [Activated] == "FALSE"
And [ActivatedLabel] != "false"
) OR (
[Configuration/Active] == True and FieldNotFilled(Activated)
And [ActivatedLabel] != "none"
) OR (
FieldNotFilled(Configuration/Active) Or [Configuration/Active] == False
And [ActivatedLabel] != "none"
)
)
a. FieldFilled(ActivatedLabel) → true
b. [Configuration/Active] == True and FieldFilled(Activated) and [Activated] == "TRUE" And [ActivatedLabel] != "true" → false since [Activated] != "TRUE"
c. Because of the OR the next subcondition must be evaluated
d. [Configuration/Active] == True and FieldFilled(Activated) and [Activated] == "FALSE" And [ActivatedLabel] != "false" → true since "none" != "false" (remember that ActivatedLabel is filled with “none”
e. We have a true in the OR and the next subcondition must not be evaluated
f. The rule fires and this is what you see.
The validation message is an error created by the SME and can be seen directly in the JSON file.
To solve the problem, you should avoid setting computed values by yourself (in this case Activated and ActivatedLabel), you should let the Kernel computations do that for you (this is indeed a good practice).
Other solution would be what I mentioned before, to simulate what the configuration mgmtp.a12.dataservices.documents.computation.cleanup-error-and-not-computed-value.enabled does, or migrate to that A12 version and activate the configuration.
