Hey, I have a question regarding a dependent enumeration that is filled, even though I would expect it to have no selection.
-
I have a group “Accident” that is cleared if “SelectAccident” is false. (Screenshot 1) (which is the case in my test)
-
Screenshot 1:
-
I have an enumeration inside this group “Disability” that is dependent on a computed enumeration field (Screenshot 2 & Screenshot 3)
-
Screenshot 2:
-
Screenshot 3:
-
I have another enumeration “TotalDisability” that is set dependent on “Disability”. (Screenshot 4)
-
Screenshot 4:
My problem: accident is false, so disability is not set (“NoAccident” case of the master enumeration field), but “TotalDisability” has still value “62000”. Do you know why?
Hi @maria-wintry-ice,
It looks like you’ve got some complex models there!
I can’t say for certain as I don’t know how the Computed Enumeration Field
/ContractHelper/ConcatendatedTypeOfAccident
is calculated but what I suspect is that one or more of the fields from
/Contract/Coverage/Accident
is referenced in the Computation Table. As a result, the following could happen:
- /Contact/Coverage/SelectAccident is set to false
- /Contract/Coverage/Accident is hidden and cleared
- The Field Value change in /Contract/Coverage/Accident triggers a recomputation of /ContractHelper/ConcatendatedTypeOfAccident
- The Field Value change of /ContractHelper/ConcatendatedTypeOfAccident triggers the Dependent Enumeration for /Contract/Coverage/Accident/LimitsDisability
- The Field Value change of /Contract/Coverage/Accident/Limits/Disability triggers the Dependent Field for /Contract/Coverage/Accident/Limits/TotalDisability
You are currently working in 2023.06 so you might not have watched the Modeling Release Presentation for 2024.06 yet. We talk about the need to exclude Data that we hide and clear (Data marked as not relevant in 2024.06) from Computation Rules so that the frontend and backend of your application are consistent (Timestamp 35:45).
I’ve created some sample models which show a simplified Version of your use-case. I have modeled:
- A Boolean Field, SelectA, that controls when Group_A is hidden and cleared through a Form Model Dependency.
- A Computed Enueration, ComputedHelper, that incorrectly references data that is hidden and cleared.
- Form Model Dependencies so that changes in ComputedHelper trigger Field Values to be set for Enum_D and Enum_TD
I can reproduce the behavior that you have seen in the Form Model Preview by:
- Setting SelectA to true
- Entering a value into F1, F2 or F3
- Setting SelectA to false
This is because clearing G1 causes ComputedHelper to be recomputed…
The solution simple. Adding a Common Precondition to the Computation Rule
[../SelectA] == True
will mean that ComputedHelper is only calculated when G1 can be used in the Form. As a result, deselecting SelectA clears ComputedHelper and the cascade of Dependencies is not triggered.
You can test this yourself in the attached 2023.06-ext6 models.
DependencyComputation_DM.json (9.9 KB)
DependencyComputation_FM.json (8.6 KB)
If you need help excluding your Fields from the Computation Rule, please feel free to ask 
fyi, there’s an analyzer that look for exactly these types of issues that you can use when migrating to 2024.06
Hi @malcolm-silver-ice ,
thanks for your answer. As we figured out together, in my case the solution was a bit different, so I would like to add it here:
My helper field did not include any fields from Coverage/Accident, but the problem was that it included two cases with precondition “…SelectA == false” (Additionally to the other two cases whith precondition “…SelectA==true”), which triggered the re-evaluation in case of de-selecting the SelectA checkbox.
Since there was actually no reason to keep those two cases (as all dependent enumerations should be null in this case), the solution is to remove these two cases from the computation and the enumeration completely.
