Hello,
we try to set read_only dynamically (with an expression), but - different to relevant and required - this doesn’t seem to work. See attached examples.
Is this not implemented in KoBoCollect?
Furthermore, it seems that read_only is not available in (Enketo) Online FormBuilder.
Thanks.
readonly
As in XForms 1.0 this specifies whether the user is allowed to enter data, using a boolean expression. Considered false() if omitted.
https://www.w3.org/TR/2003/REC-xforms-20031014/slice6.html#model-prop-calculate
6.1.2 The readonly Property*
Description: describes whether the value is restricted from changing.
Computed Expression: Yes.
Legal Values: Any expression that is convertible to XPath boolean with boolean().
Default Value: false(), unless a calculate property is specified, then true().
Hello,
still need support on this question, please.
Find attached some exercises without being able to set read_only dynamically. Read_only Dynamic 02.xlsx (10.6 KB)
Can anyone provide an example where dynamic setting s working for read_only, please.
Maybe this issue needs to be forwarded to development? @jnm
It is necessary to allow read_only to be set dynamically. Just an example: If a birth date is recorded, age can be calculated (set to read_only = yes), otherwise age has to be entered…
Sorry, I misspoke - Enketo does not yet support runtime re-evaluating XPath read-only bindings. See https://enketo.org/about/roadmap/ (“Dynamic readonly”)
Actually, after a bit more digging, Enketo doesn’t actually evaluate the readony XPath expression (!). Rather, presently it just checks whether the string is “true()” or not. So, for example, if you put read_only as “1=1” - which is always true - it will not work as expected.
Hello,
you are welcome. @Xiphware: Also KoBoCollect does NOT support??
(Different to XLSForm spec.)…
Should be addressed to the developers, please. (Since Feb. no news there).
**I there a summary list, which standard XLSForm elements from the official spec (XLSFom.org) are yet NOT implemented in KoBoCollect (or differently) **
Just to add: KoBoCollect works fine with dynamic read_only (following the XLSForm specification)… @Xiphware I suggest to add a hint in the http://xlsform.org/en/ref-table/ as it doesn’t explain the problem with Enketo, but says: “… or a statement that evaluates as true or false”.
The feature should be implemented for Enketo, as it’s useful, e.g. to preset a value and set the field to read_only dynamically, for example if the current person in a repeat is the head of household. Sorry, in general I would appreciate that features defined in the XLSForm.org specification are fully implemented in KoBoCollect and Enketo. Or a complete list of current differences to the official spec should be provided.
Kind regards
Hello @Kal_Lam, @martijnr,
Any news on this. Still seems not working in Enketo (incl. Online Validator).
github seems not much interested? But it is marked as a priority in Enketo Roadmap
If would like to suggest to add at least a hint in the http://xlsform.org/en/ref-table/ as it doesn’t explain the problem with Enketo, but says: “… or a statement that evaluates as true or false”. The same for dynamic default, please.
A typical usage would be using a choice_filter and set dynamically the valid forced option to read_only. For ex. Person is father, now in following sex question restrict to “male” as choice and set it (calculation) and show it as read_only. But if person is something else, allow free choice.
As you have noted, this remains a priority fix for Enketo, but I am not aware of any recent progress being made on this front or an ETA for a fix. In the interim if you feel it could be useful to the community to explicitly call out this difference in behavior between Enketo and Kobo/ODK, I might suggest opening as issue against the XLSForm docs about it, and/or submitting a pull request yourself with suitable documentation changes.
Are there any plans or a new ETA as to when dynamic readonly feature will be made available in Enketo webforms? It has been in the enketo roadmap for quite a while now
Need this feature very frequently on many forms. Currently using a workaround by having a separate ‘read only’ version of the question. Apart from not being an elegant(proper) solution, it also leads to overhead in already long and fairly complex forms
AFAIK this feature request is still open, but it is on the radar for the ODK Core team, who now maintain Enketo and are working on getting the Enketo XForms web client more closely aligned with the ODK Collect/KoboCollect XForms Android client.
Hi @Xiphware,
Great to here, that there is more alignment on the way, esp. as we use both in the same survey/app and we often use Enketo for (quick) testing.
Kind regards
We have also experienced and reported small differences between KoBo “Enketo” (Preview) and XLSForm Online, e.g. automatic duplicate name change by KoBo.