Hi,
I’m trying to set a default value for the "Inception Date* field using a computed value. However, I also want this field to remain editable so that users can adjust the date if needed.
Is there a way to use a computed field value as the initial value while still allowing user input?
Additional information:
In my current a12 2023.06, I used workaround with a helper field to calculate the inception date and then set the helper field value as the initial value dependency. Because the Inception date is used in the calculation, then it becomes a cyclic dependency and is no longer allowed in 2024.06.
I’m looking forward to a alternative solution for the above mentioned. Highly appreciate your help.
The short answer is no. We currently do not offer modeling support for computed initial values. There are some tickets that are looking into this (A12-13096) but there is nothing in the pipeline for upcoming releases.
As a result, any modeling solution is based on a workaround.
As you’ve seen, cyclic dependencies and computation are now forbidden as they have a large negative effect on performance.
Looking more closely at the screenshots you just added, I would propose a different modeling solution:
Computed InceptionDate
The NextMonth Field appears to be redundant. Consider using this to always compute the first day of the next month:
AddMonths(Date("1",MonthFromDate(Today),YearFromDate(Today)),1)
In addition, writing a Field Value from one Field directly in the calculation seems to be redundant as you can simply reference this Field in the Dependent Field. In your case, where this is causing the cyclic reference, I think your doing something like
Can you just remove this?
Dependent Field
I simply referenced a couple of different Fields in the Dependency.
Take a look at my 2024.06-ext4 models and tell me what you think. Updated Models using Computed Boolean
ComputedInitialField_DM.json (7.2 KB)
ComputedInitialField_FM.json (4.3 KB)
I used 2024.06-ext4 as we have the Form Model preprocessing options that allow this “initial value” to be triggered on opening.
I had a similar need in the past (a date being by default “Today”, until the user sets a business value manually) and I used 3 fields:
and anybody (= a subsequent computation, or workflows etc) needing the value should use the third field.
Yep, you see this pattern in my example models too.
Finally, we got the version 2024.06 - ext4 available on our based application.
I followed your simulation and it work well, computed value is now always shown as initial value.
Hi @malcolm-silver-ice,
Sorry that I need your help revisit this topic, because our form is now based on CDM model, and there is a bug regarding the Setting of Values by Dependencies (A12-17565). Do you happen to have any other ideas or workarounds I could try?
I’m not aware of any workarounds that solve the bug relating to Value Dependencies in CDMs. Please add your project as an interested project of A12-17565.
The only thing that I can think of is to look into Mapping Models which were introduced as an experimental feature of the Kernel in 2024.06-ext4. You might be able to map the value in that you need instead of using a dependency. However, this is a large change which involves creating multiple new models and adding code to your application.
If you need more informaiton, please feel free to start a new thread.
We’re currently dealing with this by using a checkbox on the top of the form that’s basically called “initialize fields” that needs to be checked once to trigger the dependencies. It’s not the most elegant solution but a very quick fix. Not sure if your customers would find that acceptable as a temporary workaround.