Repeat group and relevance

Support
,
1

Hello everyone,

Section-ODK repeat error.xlsx (10.0 KB)

I checked everywhere and can't seem to find a case similar to mine. I'm currently coding a very long survey on ODK that heavily relies on repeat groups.
The questions are designed that the enumerator would pre-define how many times a repeat group should open.

My issue here is that for some reason, if the enumerator enters "0" the repeat group opens once, whereas if the enumerator enters 5, it will still open up 5 repeats.

I am not sure why its behaving this way, and i am assuming its because the form in itself is very heavy though I'm not sure. It seems to work fine when testing on enketo but not on samsung Active 2, or tab A with S pen.

Has anyone had a similar problem, and if so what kind of fixes have worked?
Would appreciate any feedback.

Thank you!

2

Hi @Maya
it's not your fault if you pass any number < 1 one group will be added anyway. Probably it's related to the changes that have been implemented recently:

Repeat behavior has changed. Previously, some clients like ODK Collect prompted users to add the first repeat. Now, the user will only be prompted to add repeats after the first one. Representing 0 repetitions will require changing the form design. Read more at http://xlsform.org#representing-zero-repeats.

and the fact that we don't allow removing already added groups by decreasing the count:

If the count is decreased by a user, no groups will be deleted. This avoids accidental data loss: a user who accidentally sets the count too low can set it to a higher number and still have the repetitions that were previously created.

So I understand the scenario is:

  1. The first group is added automatically before a user passe any value
  2. Then a user pass 0 for example which is lower than default 1
  3. Since we don't allow removing groups automatically as I mentioned above that group will be still there.

A workaround would be to add an additional group inside and calculate its relevance:

image
image964×145 15.1 KB

repeat_count.xlsx (5.8 KB)

1 Like
3

Thank you so much for this, the work around worked!

4

Hello @Grzesiek2010, hello @Maya,
We hope this delete behavior will be changed soon in the new release.
The workaround is only hiding the grouped data, but the repeat itself still exists, also position(..). So you will have mismatch and problems when you use count(repeatGroup), position(..) and following references, like education details in a following repeatGroup for the HH members in the first repeat.
See also https://community.kobotoolbox.org/t/dynamic-repeat-group-does-not-work-properly-if-the-number-of-repetitions-is-updated/10353/3

5

I was searching to solve a similar warning note i got, only to see this thread. I used same workaround recommended, but after converting, i still get same warning note.

Please, should i be worried if the warning still show?

6

no, it's just a warning and using the workaround won't make it to disappear so please just test your form and if everything is fine you can ignore the warning.

1 Like
7

Thank you so much for the quick reply. I am testing it already.

8

Unfortunately (for you) we don't plan to change the current behavior.

That's true but you can use count on the inner group (gr2 in the screenshot I attached above) and it should work as expected.
Test form:
repeat_count.xlsx (6.1 KB)

9

Hello @Grzesiek2010,
Thanks for your prompt answer.

We have a lot of problems to get more complex usage of repeats working, and a big problem is that the behavior (at the moment) is very different between (KoBo)Collect and Enketo(Preview) and even between pages and default style setting. Allow me, please, to come back with a "real" more complex example in the next days, probably as new topic.

Also the documentation and forum discussion gave a lot of simple examples, like count(RepeatGroup) and referencing this for a following repeat group with repeat_count which will not work well if repeat_count is reduced are deleted.

My feeling is that the behavior also was in Collect since last year. But I am not sure. Maybe also this hint was new? https://docs.getodk.org/form-repeats/#using-a-constraint-to-limit-repetitions

I think, that now an additional internal grouping with relevant is needed ALWAYS to avoid problems. At least for Collect!
I copy @LN in, for further discussions.

The differences between Collect and Enketo create general problems for us, as during monitoring/QA we sometimes need to re-edit a few cases on the server. And this may destroy even some field data.
Kind regards

10

Yes, real use case might be helpful.

It's always worked like now.

11

Edit: Never mind, I found my answer here: https://xlsform.org/en/#only-add-repeats-in-certain-conditions
It was just above the section I was checking.

Hi. I was facing a similar issue with pre-defined repeat counters in ODK. I ask the user for an integer and then repeat the group that many times. If the user enters 0 in enketo, no problem. But in Collect it would still go on to show one repeat.
So I tried out your solution (of having a nested group within the repeat) and it worked but since I had too many such repeats to adjust, I just tried keeping the condition ${q1}>0 in the relevant field for the begin_repeat row. And it worked too! This could save me a lot of time.
Is there any reason to not keep a relevant condition for repeat groups, within the row of begin_repeat? I cannot find the "relevant" documentation for this anywhere (pun intended). Edit: Answer is No
I mean to ask, will doing so cause any problems in the data or the processing of the form over hundreds of submissions? Edit: Answer is No