This problem persist if the multi-select and the relavant question are within the same group unlike for the single select
Could you provide more details, please, e.g. screenshots of the problem. It seems to work well when I test it with the (Enketo) online validator.
Hint: In your form, infra(structure) select filters 2 questions, but human none?
your relevants are:
selected(${lulc}, 'infra')
selected(${lulc}, 'infra').
Do you use Enketo or Collect?
Design-hint: A normal select appearance will not use much more space here and might be easier to understand, esp. when deselecting.
In Collect, you have to leave the screen and come back for the relevant to be evaluated and show the additional questions.
Hi @danbjoseph,
Sorry, I thought this changed, see
Relevance, constraint and calculation evaluation within the same screen is supported in Collect v1.22 and later. (https://docs.getodk.org/form-question-types/#grouping-multiple-widgets-on-the-same-screen).
odd, I tested on the latest beta and it didn't seem to work. are you able to test on Collect and see if the issue occurs for you?
Hi @danbjoseph, @AparnaK,
I did some more tests, with interesting results:
- In Collect Only with no-buttons appearance it doesn't work directly (even not with aditional trigger). It only updates the sub-questions on leaving the page (forward are backwards, or opening the navigation/flesh menu).
- If you remove no-buttons, it works!
So, there is probably a Collect bug related to no-buttons appearance, in a group structure.
Hints:
- There are no differences if you change other things, e.g. naming of the choice_list, choice_filter = true() or sub-questions = mandatory.
- If you use columns-2 alone, behaviour is ok, in ODK Collect and in Enketo.
- If you remove the field-list appearance or the total grouping, behaviour is ok.
- Also, if you use select_one instead of multiple, it works well.
Furthermore, I found a bug (?) in Enketo:
- If you use no-buttons without a columns-n (or columns or columns-pack) appearance, the buttons are shown like in a normal select widget.
In additon, Enketo, no-buttons with columns-n (or columns or columns-pack) shows a strange positioning, e.g. columns-2
Different to with buttons
.
Here is a simple example, to show and play around sample03.xlsx (10.4 KB).
@danbjoseph, @LN. Could you create 2 or even 3 github notes, please ? (And reference them in this thread, please).
1 Like
Hi @AparnaK,
As a workaround you can solve the Collect issue by not using no-buttons appearance in groups with field-list.
1 Like
Hi @danbjoseph
I found a third problem, see update with screenshots above.
All 3 issues are around the no-buttons appearance.
1 Like
Hi!
Yes, I can confirm that there is an issue in Collect when select_multiple is used with not-buttons appearance on a field-list to update other questions.
You can track the issue in our repository https://github.com/getodk/collect/issues/5821 I hope we will be able to fix it soon.
Thanks for reporting the bug.
Hi @Grzesiek2010,
Hint: It's probably the same bug with select_one.
@seadowg. It is a problem before Beta (I tested) and with Beta (@danbjoseph tested).
Could you also review the two reported Enketo problems, please, see above? Or forward to another core team member, please?
2 bugs (?) in Enketo:
a) If you use no-buttons without any columns appearance, the buttons are shown like in a normal select widget.
b) no-buttons with columns-n (or columns or columns-pack) shows a strange positioning (with Online validator https://getodk.org/xlsform/, but ok/different with KoboToolbox, see below).
a) Online validator: no-buttons without any columns appearance. (Same in KoboTollbox)
b) Online validator: no-buttons with columns-2
KoboToolbox
No, select_one works well. I changed select_multiple to select_one in the attached form and then the issue did not occur.
HI @Grzesiek2010,
sorry, I tested again. You are right, select_one is ok. (I also updated the info above.)
Hi @Grzesiek2010, @danbjoseph,
Who will follow up for the Enketo issues, please, incl. github track entry?
1 Like
