Computed fields readonly even with unfulfilled precondition

Modeling
1

Question on behalf of @tobias-digital-tensor:

Are computed fields in the form-engine generally readonly even if the precondition is not fullfilled? Is there a way around this?
I couldn’t find anything regarding this behaviour in the documentation.

2

Hello @tobias-digital-tensor,

yes, computed fields are always read-only in the form engine, it is mentioned in the documentation in one place here: GetA12 Login

As far as I know, there is no way around it. What is your use case so that you require a computed field which is only computed under certain conditions?

3

As far as i know it is not possible to set a value in a field that’s inside a repeatable group with the dependent field mechanism. In the ui designer i see that only setting readonly/hidden is possible.
i want to prefill a field inside of a repeatable group when the user selects a specific enumeration value.
document model looks something like

{
    "StringType": {
        "template": "Enum",
        "errorMessages[100]": {
            "language": "string",
            "errorMessage": "string"
        }
    }
}

If the user selects a template value then the errorMessage should be set to a specific value dependent on the language.

So i tried to get around the limitation of dependent fields in repetitions with a computation.
That’s where i noticed that the computed field is always readonly.
In the meantime i found out that the user needs to edit the errorMessage field also for cases that the value is computed so we cannot use computations anyway. Still a bit curious why computed fields are always readonly even if no precondition is true though?

In the end i think we are not getting around using custom code for this, or what do you think?
I mean it’s a very specific use case so i guess it’s not such a big problem if it’s not possible to model this behaviour.

Thanks a lot for your answer!

Cheers,
Tobi

4

You can try to use two fields for the errorMessage here:
The first one is computed from the enum value and only shown (and used) for the enum values that fit your precondition.
The second one is editable and only shown (and used) when the enum value does not fit the precondition.
You have to make sure that only one of them is visible at all times.

It means the first field should have the computation and dependent field (for visibility) specified on it and the second field only has a dependent field for the visibility.

You could even add a third field that is computed from the other two (and never even visible) and that you can then use as the actual result in your post-processing or you do this after a form submit in custom code.

5

Hello,

hadn’t thought about that, really cool! We cannot use it unfortunately in this case because ErrorMessages is a complex type :smiley: But i keep it in mind for other cases. Thank you for the idea!

Best wishes,
Tobi

6

Hi,

in order to get additional dependency options (e.g. set Value, set Field Value), the triggering field needs to be inside of the repeatable group as well.
So you could use the following workaround:
Place a trigger field inside the repeat and compute its value based on your “template” enumeration. The computed value will be the same for each repeat entry. This field does not need to show up in your UI. Then use the dependent field option inside the UI Designer to set your “errorMessage” field to a particular value and/or read-only for particular values of “template”.

Please note, that it is not recommended to use a sequence of dependencies, e.g. FieldA triggers FieldB which triggers FieldC etc… Therefore, it is important to compute the triggerfield in your case.

I attached an abstract model example (A12 202202.2.0, SME 7.1.4, UI Designer 33.1.1) for more details.
Dependencies_D.json (5.2 KB) Document Model
Dependencies_F.json (3.2 KB) Form Model

Best