How to modify the read-only property of an invididual field in a form model based on busines logic

Engines Form Engine
1

Hello,

we have a Field of Datatype Boolean in one of our Form Models. In some cases we want to set this field read-only based on our business logic.
Is there an easy way to modify the read-only property of a single field in the Form Model after it was loaded?

Our current implementation uses an intermediary Trigger Element and a custom Saga to change the state of a Document Model Field to then achieve changing the read-only property in the Form Model.

Best regards,
Jonas

See
grafik

and

grafik

2

Hi @jonas-silver-ledge
Can you give some more details regarding your use-case as it isn’t clear to me if this is a pure modeling topic or something where you need custom code.

What I believe is happening is:

  1. There is a data change
  2. The new data should be evaluated and the value of “angenommen” should be set to true or false
  3. If “angenommen” is true, all controls that reference “angenommen” should be read only.

The reason I ask is that if the data change that happens in step 1 relates to data on your document, then you can simply use a computed trigger field (similar to how you are currently using readOnlyAngenommen).

If the data change happens on a linked document, then you can do the same thing with a Composed Data Model.

Is the requirement that the user can check “angenommen” but once this box has been checked, it should be set to read-only so that it can’t be unchecked in the form? If so, have a look at the attached models (2023.06-ext6) where i use a computed trigger field to set this.

ReadOnlyWhenTrue_DM.json (2.9 KB)
ReadOnlyWhenTrue_FM.json (2.1 KB)

Please remember:

  • Setting a control to read only does not change the user’s right to change the field value. It just changes how that particular control is rendered.
  • We recommend using Confirms for two value logic.

I believe “angenommen” should only take two states and you might consider changing this before you migrate to 2024.06

3

Hi @malcolm-silver-ice,
thanks for your quick reply!
I noticed that my provided screenshot had an error. Maybe that contributed to the confusion - sorry for that. The correct screenshot is appended below.

Regarding my question:
Our goal is to change the property of a Form Model Field (“angenommen”) to be either read-only or editable, based on our business logic. For certain users the field should be editable, for others it should not. Is there a way to achieve this more easily than our current implementation (which is explained below)?

More precisely: Can we enable/disable the read-only property for a single field in a Form-Model via custom code without a change to the document model?

Regarding your assumptions:

  1. The data change is not the initiator. The Form Model is loaded by a client and then our business logic is evaluated. Based on the business logic “readOnlyAngenommen” is set to either true or false. That change currently triggers “angenommen” to be readOnly or editable (-> see Screenshot).
  2. The value of “angenommen” should not be changed via this logic. Only its read-only property.
  3. No. “Angenommen” should not trigger any additional changes.

Our current implementation works but feels a bit hacky:
Via the SME we configured a dependent field (“angenommen”) and an intermediary trigger field (“readOnlyAngenommen”). After the Form Model is loaded, our business-logic is evaluated via custom code and sets “readOnlyAngenomen” to either true or false in the Document Model. This change triggers the dependent field (“angenommen”) to be read-only if “readOnlyAngenommen” is true.
grafik

I hope that makes my question more clear.
Best regards,
Jonas

4

So this topic is covered by Enablements. Enablements allow modelers to combine different aspects of business logic and use this information to set dependencies. Applying this to your case, this means that you could define the roles which would lead to this field being read-only.

Now it’s time for the good news and the bad news.

  • The good news is that this solution will be / is modelable (less custom code) and you wouldn’t need to change your Document Model

  • The bad news is that this feature isn’t complete (A12-10152).

I’ve already alerted my more technical colleagues to your question so let’s see if there’s an easier solution that we can offer you based on custom code that works right now.

5

Hey all,

it does indeed sound like a use case for UI enablements, so I wanted to add my perspective as a modeler in a project that uses UI enablements: it may be not as comfortable to model as one is used to in A12, but it is very much possible for a non-dev person, as long as you are comfortable making changes in a json directly. There is SME-support, but it is not very convenient to use it to edit the json file in which the UI enablement rules are being defined (but possible). I want to note that UI enablements, as the name indicates, only determines what can be done in the front-end, so in addition, a field needs to be secured in the back-end as well if applicable (which should be the case in your current solution as well, I guess).

I appreciate this feature a lot, it saved us from a lot of tedious work and headache, so this is my advertisement for using it :smiley:

So far, we use UI enablements for these things (not sure if there are more possibilities):

  • make all fields in a control grid in a form read-only/editable
  • display/hide a button in a form
  • being implemented right now: make all fields in a section or screen read-only/editable
  • (I think it is also possible to hide fields in a control grid/section/screen, but not sure)

depending on

  • user role
  • a field value (status in our case)
  • a combination of user role and field value

Although it is not officially part of A12 (?), we have been using it for more than a year now and <PROJECT_NAME> is in production with it.

6

Hi @jonas-silver-ledge,

did one of the replies answer your question or do you need further support? If it is solved, please, use the checkbox to mark the solution to your problem so that other users also know what helped in your case.

Denise from the Discourse team