Dynamic values are not always populated in form choice labels

[jkuester]

Generated place name is not working after upgrading cht-conf to 6.0.2. Could it be related to this issue?

I tested it with clinic-create form in the default config.

cht-conf@5.6.0

cht-conf@6.0.2

Originally posted by @binokaryg in #640

[jkuester]

Okay, so here is some details I have found. The bug is reproducible with any form that interpolates values from the data model into a choice label. So, the most simple repro is something like:

survey

type	name	label::en
text	name	Name
select_one names	select_name	Select Variant

choices

list_name	name	label::en
names	mr	Mr. ${name}
names	mrs	Mrs. ${name}

In this form, for the select_name question, the entered name value should be rendered for the select options, but it is not (when the form is converted with 6.x of cht-conf). When using 5.x of cht-conf, the name value is rendered as expected.

---

Looking at the difference in the form xmls that are generated by the different versions of cht-conf, the key changes are around the select1 question structure in the form body:

5.x

    <select1 ref="/data/select_name">
      <label ref="jr:itext('/data/select_name:label')"/>
      <item>
        <label ref="jr:itext('/data/select_name/mr:label')"/>
        <value>mr</value>
      </item>
      <item>
        <label ref="jr:itext('/data/select_name/mrs:label')"/>
        <value>mrs</value>
      </item>
    </select1>

6.x

    <select1 ref="/data/select_name">
      <label ref="jr:itext('/data/select_name:label')"/>
      <itemset nodeset="instance('names')/root/item">
        <value ref="name"/>
        <label ref="jr:itext(itextId)"/>
      </itemset>
    </select1>

[jkuester]

I can also reproduce this by uploading this form to https://getodk.org/xlsform/ confirming this is actually a bug in enketo-core (and not in cht-core/cht-conf). I have submitted a PR fix to enketo-core: enketo/enketo#1485

The bad news

Since the issue is enketo-core our options here in cht-conf for fixing it are...limited. The differences I noted above in the form.xml are non-trivial and are the result of the newer version of pyxform/ODK fundamentally changing how choices lists are structured in the xform. I do not think it is feasible for cht-conf to try and "massage" this structure back to what it was before.

In cht-core we could manually include the changes from my enketo-core PR in a patch and ship the updated logic without making any other changes to our Enketo setup. However, assuming my PR is accepted, I think it would be better to just use this as motivation for medic/cht-core#8755 and uplift to use the version of Enketo with the fix. Of course, in either case this would only fix the issue for new versions of the CHT.

The "good" news

There is a workaround. As I noted in my enketo-core PR, the problem behavior actually only happens in forms that do not have a repeat. For forms with a repeat, the dynamic values are rendered properly (even if the repeat is never relevant).

So, for the the originally reported issue with the default place create forms, I was able to "fix" the issue by adding this to the inputs group (it is not displayed to the user because the inputs group is not relevant):

type	name	label::en
begin_repeat	797_workaround	Not used
note	info	This repeat is included as a workaround for https://github.com/medic/cht-conf/issues/797
end_repeat	797_workaround

---

@binokaryg I would appreciate your thoughts on the best next steps here! Is the workaround + fixing it in cht-core/enketo-core enough of a resolution? I worry about the confusion this problem can cause since it is a subtle runtime issue that might be hard to catch in many cases (I missed it when shipping the changes to the default forms...).

It might be feasible to add a form validation to cht-conf that would try to check for forms that use dynamic values in choice labels and do not have a repeat. We could trigger a validation error and reference this issue/workaround so at least the app-dev would have an idea of the problem and a path forward for fixing it. We can also scope the validation so when we update cht-core with the fix, the validation only runs if you are targeting a CHT instance running an older version.

Does something like that make sense or do you have any other ideas here?

[binokaryg]

I agree. The workaround with an integrated warning/notice in cht-conf could be a good middle ground. It ensures app developers are aware of the issue without requiring immediate intervention or breaking their current workflows.

Since this is already present in the default contact forms, many other forms are likely affected. A targeted validation that points to this issue/workaround would be very helpful for the community.