# N repeats defined by another question

Hi there, not sure if this is a bug or perhaps by design, but in a
household survey we use a question to define the number of times a repeat
group should be repeated e.g. (Q1) how many people live here? If the answer
is 2 then there will be two repeats of the group asking each individual
questions e.g. (Q2) What is your name? This all works perfectly if you have
entered the correct number of people in the house (Q1) or less than the
correct number ie one can go back and change the people answer to 3 and a
third repeat group will be added.

Unfortunately if you overestimate the number of repeats in Q1 e.g. you
answer 3 AND you start the 3rd repeat group then returning to Q1 and
correcting it to 2 does not reduce the number of repeat groups to 2. It
therefore seems that Collect is not re-evaluating the repeat group number
if a prompt in that nth repeat has been visualised.

I have attached a very simple form to demonstrate. Simply enter 2 in Q1
then thumb through to the second repeat of the group, go back to Q1 and
change the answer to 1 and you will see that Collect still asks for the
names of 2 people....

Hope the above is clear. Its not a major issue, but was surprised when I
saw it.

Thanks to everyone involved in odk - its a great piece of software!

Test.xml (1.54 KB)

Created an issue for this:

It is unlikely this will get fixed anytime soon.

··· On Wed, Jun 12, 2013 at 6:30 AM, dj_bridges wrote:

Hi there, not sure if this is a bug or perhaps by design, but in a
household survey we use a question to define the number of times a repeat
group should be repeated e.g. (Q1) how many people live here? If the answer
is 2 then there will be two repeats of the group asking each individual
questions e.g. (Q2) What is your name? This all works perfectly if you have
entered the correct number of people in the house (Q1) or less than the
correct number ie one can go back and change the people answer to 3 and a
third repeat group will be added.

Unfortunately if you overestimate the number of repeats in Q1 e.g. you
answer 3 AND you start the 3rd repeat group then returning to Q1 and
correcting it to 2 does not reduce the number of repeat groups to 2. It
therefore seems that Collect is not re-evaluating the repeat group number
if a prompt in that nth repeat has been visualised.

I have attached a very simple form to demonstrate. Simply enter 2 in Q1
then thumb through to the second repeat of the group, go back to Q1 and
change the answer to 1 and you will see that Collect still asks for the
names of 2 people....

Hope the above is clear. Its not a major issue, but was surprised when I
saw it.

Thanks to everyone involved in odk - its a great piece of software!

## --

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thank you! A very clever fix and an intriguing idea -- I have no idea how
javarosa handles that 3rd repeat group during a save.

Mitch

··· On Wed, Jun 12, 2013 at 8:15 AM, wrote:

A fix that worked for me was to include a relevant condition for each
question in the repeat group. The condition should look like the following:

\${position}<=\${hhsize}

The variable 'hhsize' represents how many times you want the group to
repeat (i.e. once for each member of the household). The variable
'position' is the result of a calculation with the function position(..),
which returns the current repeat number of the group.

With the above relevant condition, if at first you set hhsize to be 3 but
then later on change hhsize to be 2, you will not reach the 3rd repetition
because the relevant condition fails.

Also note that if any data was entered for the 3rd repeat I think it will
still be there, which may need to be deleted during back-end processing,
but at least the surveyors will not be presented with the 3rd repeat.

I've attached an xlsform example of how to implement the relevant
condition.

On Wednesday, June 12, 2013 7:00:23 PM UTC+5:30, dj_bridges wrote:

Hi there, not sure if this is a bug or perhaps by design, but in a
household survey we use a question to define the number of times a repeat
group should be repeated e.g. (Q1) how many people live here? If the answer
is 2 then there will be two repeats of the group asking each individual
questions e.g. (Q2) What is your name? This all works perfectly if you have
entered the correct number of people in the house (Q1) or less than the
correct number ie one can go back and change the people answer to 3 and a
third repeat group will be added.

Unfortunately if you overestimate the number of repeats in Q1 e.g. you
answer 3 AND you start the 3rd repeat group then returning to Q1 and
correcting it to 2 does not reduce the number of repeat groups to 2. It
therefore seems that Collect is not re-evaluating the repeat group number
if a prompt in that nth repeat has been visualised.

I have attached a very simple form to demonstrate. Simply enter 2 in Q1
then thumb through to the second repeat of the group, go back to Q1 and
change the answer to 1 and you will see that Collect still asks for the
names of 2 people....

Hope the above is clear. Its not a major issue, but was surprised when I
saw it.

Thanks to everyone involved in odk - its a great piece of software!

## --

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thanks for the workaround nixlisong - works great for me. I can confirm
that the additional repeat group is saved even though it is no longer
visible, but this can easily be weeded out once data has been downloaded
from Aggregate.

Thanks for checking it out mitch and posting a bug report.

Are the actual values saved for the extra groups that are no longer
relevant, or just blank responses? Usually, non-relevant field values are
emptied automatically, which I had assumed would be the case here. If not,
that's more of a potential issue for users of the data on the back-end.

Thanks,

Chris

··· On Thu, Jun 13, 2013 at 9:26 AM, dj_bridges wrote:

Thanks for the workaround nixlisong - works great for me. I can confirm
that the additional repeat group is saved even though it is no longer
visible, but this can easily be weeded out once data has been downloaded
from Aggregate.

Thanks for checking it out mitch and posting a bug report.

## --

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an

the form, rather a blank line is entered into the csv file which should be
easy to remove on the backend.

Once again nixlisong - great workaround!

··· From my limited testing, it seems like any values entered are not saved in

Great, thanks for letting us know. That behavior makes sense: the group is
there in the form instance, so it outputs, but everything is blank because
the fields aren't relevant. I suppose that, in such cases, Collect should
automatically delete all groups over a revised repeat-count -- but that's a
little bit scary since it can delete data that's been entered.

Best,

Chris

··· On Fri, Jun 14, 2013 at 8:01 AM, dj_bridges wrote:

From my limited testing, it seems like any values entered are not saved in
the form, rather a blank line is entered into the csv file which should be
easy to remove on the backend.

Once again nixlisong - great workaround!

## --

You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an