Collect: Repeat instances not removed after repeat_count was reduced

Support
1

Description

Cases are not removed after repeat_count was reduced (KoBoCollect). ALL previous cases stay visible and active. Also the count() is not updated.

Steps to Reproduce

See XLSForm attached, with Remarks.
BugIV_02.xlsx (31.7 KB)

  1. Import form and open it
  2. Enter 3 for Total of HH members
  3. Fill names
  4. Go back and reduce Total, e.g. to 2
  5. You will still see all previous cases
  6. Finalize and save and re-edit
    You will still see ALL previous cases.

Expected behavior

Cases of repeat_group should be reduced, to the new repeat_count
As it works in Enketo/Preview (in default style)

Actual behavior

All previous cases are still there. This will not change, if you finalize, save and re-edit.

More information

This has been previously reported and discussed at on this Kobo forum thread. I'm opening a post here because Josh pointed out that this is a better place.

2

Here's a previous discussion that may be useful:

3

Thanks a lot, @danbjoseph ! I like the approach described in that discussion, even though it feels more like a workaround than a solution to me.

I'd love to see a bit more discussion about the intent of this feature. In my experience, the current behavior is somewhat problematic:

  • It generates inconsistent data.
  • What's worse, there is no way to decide how to resolve the inconsistency: I don't know whether the repeat count is too small or whether there are too many repeat instances. The enumerator has no way of telling me.
  • Similarly, even if I knew that there are too many repeat instances, I don't know which ones to keep. I could arbitrarily keep the first n-1, but that might not be what the enumerator wanted.
  • In my experience, explaining this "feature" to enumerators is really tricky. They don't understand why their change to the repeat count has no effect.
4

I would welcome other people's opinions and experiences! What do you think the optimal behavior should be?

5

As I wrote in Getting more repeat instances than expected when submitting from Collect - #7 by LN

I think a good next step would be to see whether there's a logical and reasonable way to get the behavior achieved with the inner group with relevance without having to do a form design trick. I'm not sure how feasible that is. The core team won't have time to prioritize this in the short term but it would be a welcome contribution.

6

Could you point me at (roughly) the place where I could add a testcase for this, and possibly also where the code would need to be adjusted?

I can't promise that I will be able to implement this, since I can't really estimate the complexity at this point. But I'd be happy to take a look.

7

I would also like to add an idea:

My preferred solution would be a warning popup that appears when the repeat count is reduced. Something like: "Changing <variable name> will delete <x> instances of <repeat group name>. [Yes, delete] [Cancel]"

That might be a little tricky to implement since the variable might be linked to a repeat_count in complex ways... but maybe it would be enough to handle the common case where the repeat count is ${variable name}.

8

Hi,
The offer to potentially contribute some code still stands, but I'd really need someone to spend 15 minutes to introduce me to the codebase.

9

Thanks, @Sjlver, looking at the PR linked from the issue described above should get you in general area. You'll see we discussed the concept of a warning when the repeat count is reduced and that it would require a fair amount of restructuring.

1 Like