I have been made aware of a bug where relevant questions are not displayed in the first record of a repeat, if accessed from the Drafts, Sent or Inbox. This means data recorded in the first nest of repeats is potentially going missing unless it is submitted straight away. Could you let me know when a fix will be released for this as it is a big issue for us.
We are still experiencing this bug using Build 3.0.149, in which the bug was said to be fixed. We are losing data from the first repeat of a survey response after reopening from the inbox, drafts, or sent box. It is not just the case that it is not displaying - the data is being lost, which is a pretty major issue.
Thanks for raising this to our attention. Could you share your XLS file? There might be a difference in the form design compared to the other cases that were reported.
Thanks for attaching the survey, I am taking a look at the issue. A few questions, was this survey and the repeat values when loaded from Inbox working correctly before 3.0 update? Is the issue you see now only since 3.0? If you have more than one repeat record and load from Inbox, do you see 1 of 3 for example in the repeat, or 1 of 1? ie do all 3 records load but data missing in first, or none of the records load?
Another thing to note is that I see you are using default values for select one questions that are not in the choice list. This causes the value to be striked out, and then when a new value is selected from list the strike out remains. We have an open issue for this but just thought I would point it out.
I have just tested version 2.7.98, and do get the error. I find the error is not consistent - the first survey I fill in seems to be OK, then the error seems to occur in a second.
If, for example, there are 3 records in the repeat, all 3 load, but data is missing from the first.
Thank you for pointing out the striked out values - we may rethink that, although it does not appear to affect the data.
Thanks for the extra info. I have just tested with 2.7 and 2.8 and the survey appears to be working correctly and all repeat values are loaded and displayed when using Drafts, Sent etc. If you are having issues with Inbox with 2.7 version then it is likely because there is no query clause on the repeats, which is used to load the repeats from Inbox, this works differently compared to Drafts and Sent which loads everything as it is already local on the device.
You need to add the following query to the begin_repeat questions in the bind::esri:parameters column to be able to update and add new records to repeats: query allowUpdates=true allowAdds=true
More info about repeats can be found here: Prepare for editing existing survey data—Survey123 for ArcGIS | ArcGIS
The above doesn't explain why when open from Drafts or Sent box you do not see values in the first repeat record, using the latest version of the app, which I am still looking into.
Another thing to note, I see you are using minimal, compact minimal and horizontal appearances on groups. Note that only compact and field-list appearance is supported on groups as per the documentation.
And I assume you know that the null esri field type being used on select_multiple BRYO or other means that no field is created in feature layer and therefore no values is ever submitted and stored for this question. Therefore when you open from Inbox it will always be null.
Further to my comments above, I have been able to narrow down the issue to be a bug with relevant statements inside a repeat referencing questions outside of the repeat. This causes the first record repeat values for those questions with the relevance to not be displayed when loaded from Inbox, Drafts, Sent box etc.
We will work on this issue and aim to release a fix for it in our next release. In the meantime the only way to overcome this issue is to remove the relevants on the questions inside the repeat that reference questions outside of the repeat. Applying relevants on the begin_repeat question will still work as expected though.
Another issue I noted is that your choice lists contain commas and spaces, as per the Survey123 documentation special characters are not allowed in the name field of choice lists (as well as name field of question name): Quick reference—Survey123 for ArcGIS | ArcGIS