Support `NO_LABEL` functionality

[jkuester]

Support NO_LABEL functionality:

• 8cde243...cd76ce3
• Also has some changes in 88e752b

The point of the NO_LABEL functionality is that (historically) pyxform would not allow for fields/groups in an xform to have an empty label value. This custom feature meant that if you added the string “NO_LABEL” in your xform label column, then the resulting form would not display any label for that field. We should do some investigation to see if labels are still required for everything in pyxform or if there is now a more official way to support this (though medic/pyxform will still need to support NO_LABEL for backwards compatibility).

We should also do a bit of investigation here to understand exactly why these changes are necessary in pyxform when cht-conf also contains code for replacing the NO_LABEL value.

@Omswastik-11 - Please leave a comment on this issue and I will get it assigned to you! 👍

[jkuester]

Okay, I did some more digging here. It seems that the core NO_LABEL functionality (to replace the "NO_LABEL" string in field labels with an empty string) is supported by the cht-conf logic that I have linked above. These chnages in pyxform were required because the empty <label></label> blocks caused extra whitespace to appear when the form was rendered (medic/cht-core#4682).

However, I am no longer able to reproduce that excess whitespace in the rendered form (when running with the current xlsform_v3.0.1 branch code without the changes from #33). I still see the empty <label></label> blocks in the form xml, but I think the newer version of Enketo is better about not rendering theses. (Presumably because empty label blocks are intended/supported when a hint is provided. I have tested this both on 4.21.0 and 4.2.0, so support goes back at least to the bit Enketo uplift of 4.0.0.

TLDR: I do not think we actually need these changes in pyxform now because newer versions of Enketo (for CHT 4.x+) support the empty label tags. The cht-conf functionality for replacing NO_LABEL with an empty string seems to be sufficient for supporting the Medic form behavior of allowing fields with no label or hint value (which technically are out of spec.) I am going to close this issue for now, but we can re-open it later if it turns out I missed something here.

[jkuester]

So, it turns out I was a bit mistaken about this functionality. Upon further testing, I have realized that the label validation on our old version of pyxform seems to be completely disabled. I thought you had to still put NO_LABEL in the xslx or pyxform would throw an error. However, it turns out on the old pyxform, if you convert a form that just had a question/group/etc with an empty label (no NO_LABEL value or anything) it lets you do this and does not give any error. You only get a warning printed like:

[row : 292] Question has no label: {'type': 'begin group', 'name': 'meta'}

So reopening this because I think we need to do one of these things:

1. Decide that in the new (major) version of cht-conf where we will ship these pyxform changes, we will require NO_LABEL to be set instead of just leaving the label empty.
2. Push another pyxform update that re-disables all the label validation (but leaves the warning).
3. Push another pyxform update that disables the label validation and the warning. Update cht-conf to warn the user that NO_LABEL is deprecated (when they use it) and suggest they just leave the label empty.

I have gone to great lengths to not require any form changes from this pyxform uplift, but we have been giving folks that warning in the console for years. Plus the fix is super simple (just add NO_LABEL). So, I am leaning towards #1, but I have confirmed we do have production forms with this issue....

If we require NO_LABEL and leave the updated pyxform as it is currently, you will see an error like:

ERROR Could not convert /path/to/xlsx: The survey element named 'meta' has no label or hint.

It seems confusing to me that we support NO_LABEL (and most forms use it) but also you can just leave the label empty and it is fine...

---

What is confusing to me is that I cannot figure out what is up with the NO_LABEL code changes that I linked to originally in this issue. My python is pretty bad, but it seems like we are trying to actually treat the NO_LABEL value as if it was an empty label in the has_label function. But, the end result is somehow that the "has no label or hint" error is never thrown.... 🤔

@dianabarsan can I get your thoughts on this? Which option would you prefer?

[dianabarsan]

I generally tend to dislike magic constants, so my preference is to allow the empty label without the NO_LABEL constant.
Does pyxform do other label validations except for this Boolean check? Is it worth it to keep it enabled?
I think I would go with #3 and not let our workaround implementation leak into forms.

[jkuester]

🤔 I like your point about magic constants! Long-term it feels better to just let the labels be empty in the xlsx files...

I will do some testing and try to confirm any other downsides to disabling the label validation, but I am optimistic that it should be pretty safe. Currently, in normal pyxform, labels are not required on calculate fields or on groups/repeat with the field-list appearance.

As far as I can tell the xform spec requires a <label> element in the form control, but it does not actually have to contain text. Pyxform goes further, though, and requires a value for either the label or the hint. So the question of "spec compliance" is a bit complicated here, but NO_LABEL seems to unfortunately be CHT-specific.