Hi KoBo Community,
Please, I urgently need your help.
I created a KoBo form and uploaded a CSV file under Settings → Media. On the web version (using the form link), everything works perfectly: based on the selected work order, some questions auto-populate correctly, and other conditional questions appear as expected.
However, when using the same form in the KoBoCollect Android app, the behavior is different. No matter which work order is selected, the questions that should auto-populate do not, and the conditional questions that should appear remain hidden. It seems as though the CSV media file is not being read at all in KoBoCollect.
This issue is time-sensitive, and I would really appreciate any guidance or suggestions on how to resolve it.
Thank you in advance for your support.
Kind regards,
Abhas
Are you able to share your form (and CSV)? Its a bit tricky to debug what might be happening with your specific form otherwise… But suffice to say, form media files are fetched by KoboCollect upon downloading your form, just as they are for Enketo/web forms.
1 Like
Hi @Xiphware we are both new members to the kobo community so we are not allowed to attached files here. Can you share your email so we share with you?
I’ve bumped you up; please try posting now.
1 Like
@Xiphware Please I’ve shared the files to your email. Many thanks for your help.
Thanks a million in advance.
@Xiphware Please any update? Thanks
He tenido un problema similar donde funcionaba bien en el navegador pero en la app no, Esto se debía a la configuración regional del dispositivo Android, en mi caso es español Colombia y el separador de columnas que se usa es: ,
Y el .CSV usa como separador: ;
Mi solución es abrir el .CSV con un editor de texto y cambiar todos los; por , luego guardar como .CSV, y cargarlo nuevamente al formulario, implementar y de esta forma funcionaba tanto en el navegador como en el aplicativo de Android
(apologies for the delay - I just returned from vacation)
As @Luisfer1492 suggested, the issue appears to be that your CSV is using a semicolon (or even a space+semicolon) delimiter. CSVs - that is, Comma-Separated Values - should be just that: comma separated. I also noted that in your original file, some fields had a single semi-colon ‘;’ between them, whereas other had a space followed by semi-colon ‘ ;’ between the two values (or, equivalently, some of the values have a trailing space?).
After replacing all these with a comma ‘,’ the resulting new CSV is
work_orders_list.csv (1.3 KB)
After deploying the form with this revised CSV, the form appears to behave equally under Enketo and KoboCollect.
Enketo:
KoboCollect:
all the values appear to be getting pulled out of the CSV correctly:
2 Likes
Thank you very much for the clarification, and welcome back from vacation.
While the auto-populated columns work correctly when a work order is selected, the skip logic still does not seem to function as expected. Specifically, the columns that should appear based on the selected activity are not showing up at all. Regardless of the work order chosen, none of the activity-specific fields are displayed.
We have tried several approaches to resolve this but are still facing the same issue. Could you please advise if there is a specific solution or something we may be overlooking?
Thank you again for your continued support.
Best regards,
Abessolo Abhas
This problem is actually nothing to do with the CSV or pulldata, but rather with the regex() expressions that you have against ${activity}
Specifically, Enketo and Collect’s implementation of regex differs slightly; in particular, Collect’s basically matches the entire string value, irrespective of whether your regex expression has an explicit ‘^’ start or ‘$’ end delimiter. So, for example, your regex
regex(${activity}, '^(LP00[7-9]|LP01[0-5]|LP01[8-9]|LP02[1-9]|LP03[0-6]|LPC00[1-3]|E00[1-9]|E0[1-3][0-9]|EC001|M00[1-9]|M0[1-2][0-9]|MC00[1-6])')
in which you are attempting to match the activity code prefix, will work as intended in Enketo, but will always fail in Collect because the ${activity} string value actually contains bunch of additional text at the end; eg
M018 - Line Slashing 5 x 3
So what you’ll need to do is add something like a ‘.*$’ to your regex to accept these trailing characters. This will then work under both Collect and Enketo.
FWIW this regex issue is described in some detail here, and the associated Collect/javarosa issue - with all all the gory historical background - is here: Out of spec behavior of the xforms regex function · Issue #531 · getodk/javarosa · GitHub
1 Like
@Xiphware Thanks a million bro. It worked well 
1 Like
