Setting values for KoBoCollect internal variables

Hi,
Is there is any possibilty to SET and to query (some) KoBo “internal” variables, like jr:constraintMsg , via XLSForms (or something else, without having to recode Forms externally.).?
Best regards

Short answer: no.

jr:constraintMsg isnt so much an ‘internal variable’ (to Kobo), rather it is an explicit binding setting in the XForm definition which the client (KoboCollect, ODK Collect, Enketo) must abide by. And, as defined in the ODK spec it must be either a string constant or an itext() translation. Period.

So, short of adding a new feature to the ODK spec whereby the jr:constraintMsg may contain an arbitrary XPath expression that will be evaluated at runtime - which you could then conceivably exploit to generate arbitrary messages - you’ll probably have to live with the way it works now (or workaround it by optionally displaying notes for your hint instead when users do something wrong…).

Feel free to open a feature request against ODK - here - but to be honest, unless you are able to contribute the development resources needed to implement such a change to the ODK Spec, I dont think it’ll get a high priority, sorry. :frowning_face: [but I will raise the idea with the ODK dev team].

2 Likes

Thank you very much for quick answer. And the background explanation too. (It’s like an Easter egg even. (-: )

Would be great, if the jr:constraintMsg=“message”` could be enhanced to allow string ${variable} reference (like labels), so it might be set by calculate before being show…

The question was more general, even. For example the enumerator entered 2 (different) variables at 2 places, but later she changes/corrects one, so the other one (previously entered) would need an automatic update… E.g. the user deletes or changes a person of the roster after starting with individual questionnaire of the person, e.g. the person is not a “usual” household member or not the real “Head of the household”, and the related record “links” and variables would need correction.

How best design / care for deleting with dependency (e.g. individual) records is a related question for us. I will put this in an extra topic.

Best regards