Indexed-repeat used in a repeat nested in a repeat returns wrong value

Sorry! I will stop making excuses and take a look right now!

@ggalmazor, I just meant to send a gentle reminder/get update, attempting a joke :slight_smile: Hope it passed as such. Am very glad you're taking the time for this!

1 Like

Not at all, don't worry! Also, thanks for your patience. Not many issue reports get backlogged so much, and that's on me.

I'll take the chance and report that I've done a quick sanity check with Briefcase to see the shape of the data you've shared. So far, so good. Now I'm trying to get Aggregate to publish stuff to Google sheets :stuck_out_tongue:

What version of Aggregate are you running?

OK, managed to publish the form here https://docs.google.com/spreadsheets/d/1EMNQqt-PBgtdWpTjNPWsscvGe4npRhZDJoVNamlnsY0/edit?usp=sharing

Hi, @Effy!

I think I'm not understanding the whole workflow you're following. Are you using Aggregate to publish the form to Google Sheets? In that case, I can't reproduce your issue. This is a GIF of me navigating the published data:

Effy%20issue%201
(Don't mind the change of IP address in the GIF. It's because I'm running it Aggregate on my computer)
(Exporting the form to CSV using Aggregate and then importing it as a new spreadsheet gives the same results)

I've also exported the form using Briefcase and I can like each files PARENT_KEY column values to their corresponding parent file's KEY values, so I can link every piece of data up to the main CSV file.

Could you describe the steps you do to reproduce the issue detailing whichi tool you use for each step, please?

Hmmm I think I got confused in my previous answers. I get the same result you did, my issue being that when publishing to Google Sheets directly from the Aggregate server online (appspot), there is no "direct" parent_id that can be used to link the length_repeat data with the catch_repeat.

I understood that when using Briefcase, there is a PARENT_KEY value appearing, but I did not want to have to use Briefcase... (for several reasons, this is meant to be shared/used by other colleagues)

Is there no way to have the length_repeat ID link with the catch_repeat on GoogleSheets? That links me back to my first post, as I've tried to create a specific ID while designing the form, to link the catch_repeat and length_repeat - and failed :slight_smile:

Hoping this is clear

OK, I think we've zeroed on the issue now :slight_smile:

Aggregate doesn't export/publish those KEY/PARENT_KEY values like Briefcase. Aggregate exports and published data is meant to be navigated manually (like I do in the GIF I've attached). This limitation is especially obvious when you have repeat groups, like yourself.

In your case, I think you should have to change your workflow and include Briefcase to pull the form, extract some CSV files and then import them into Google Spreadsheets. That way, you'll get all those KEY/PARENT_KEY values you need to link data together.

Argh, ok - that is what it seemed like, but I had hoped there was a way through Aggregate, or at least could not have a clear confirmation until now. Good to know!

But going back to my first post, do you have an idea why I get this error when creating a custom ID myself?

Thanks for your time!

Can you please share the exact indexed-repeat call you tried? I would have expected something like indexed-repeat(${catch_repeat_ID}, ${catch_repeat}, position(../..)) but I just realized that this appears to be broken for nested repeats. I will investigate further and report back (tech details: this is because the conversion for XLSForm now puts a relative reference for ${catch_repeat_ID}).

In the mean time, you should be able to use ../../catch_repeat_ID for your calculation instead of a call on indexed-repeat. The first .. means "go up one level from the current question", the second .. means "go up one level out of the length_repeat" and catch_repeat_ID should get you to the value that you need.

Hello!

Sorry my answer is late, but thank you for looking into it.

I have used indexed-repeat(${catch_repeat_ID}, ${catch_repeat},position(..)-1) .

Have tried with your suggestion (in the calculation field, using "../../catch_repeat_ID"), but I can't upload the form on the server.
Error: Problem with JavaRosa Parsing Form: org.opendatakit.aggregate.exception.ODKIncompleteSubmissionData: Javarosa failed to construct a FormDef. Is this an XForm definition?

Although it does upload with previous indexed-repeat.

Let me know if you come across something else,

Many thanks

Effy

What version of Aggregate are you running? Are you on AppEngine?

It is on AppEngine yes!

And what version is it? Aggregate v1.7.3 is the latest that supports AppEngine. I know there were some issues with relative references with some older versions of Aggregate so that is why I'm asking.

Ooooh... I've been trying to look on the appspot, can't find the info. Where can we find the version? Have asked other team members if they know... Sorry, haven't set up the server so a bit confused!

This documentation section describes how to find your Aggregate version. The page describes why and how to upgrade Aggregate.

Hi, thanks again for your answer. Just to be sure, if there is an update available for Aggregate, that might solve the error with the ../../catch_repeat_ID calculation field?

Unfortunately I now need to wait for colleagues to check all this as I don't have necessary access. Hoping I can get that moving pretty soon! Thanks anyway.

The Javarosa failed to construct a FormDef error you're getting strongly suggests that there's an issue with the version of Aggregate you're running.

I am confident that my simplified form works on Aggregate 2+: indexed-repeat-nested.xlsx (4.9 KB) . There should be no difference between 2+ and 1.7.3 in terms of form evaluation because they have the same version of JavaRosa. What you could do to be certain is to try your form on the Aggregate sandbox. The form definition will be public while it's on there but you can delete it once you've verified it uploads.

Even if you're able to update and that fixes everything, it would be helpful to know what version of Aggregate you were using so that we can document the bug you're running into.

Thanks a lot again - you're right, we're on 1.4.15!

Will ask the team to update it. Thanks again, sorry for the late answer,

And best wishes for end of the year celebrations!

1 Like

Hopefully you were able to get things working with ../../catch_repeat_ID instead of a call on indexed-repeat. For others interested in this conversation, I did indeed confirm that there was an issue with indexed-repeat in nested repeats and it should now be fixed in Collect v1.26.3 which was just released.