Issue viewing attachments in feature service from Surveys submitted from Inbox

2646
11
01-26-2018 10:44 AM
RobertMarros
Frequent Contributor

Question for Survey123 development team:

 

We have constructed a survey containing a repeats block that includes several regular attribute fields (text, select_, etc), but also an image field.  The repeats block also contains a geopoint field so that a related feature class to the survey's main feature class is created.  We have configured the repeats block with 'query allowUpdates' in the bind::esri:parameters column using the instructions from the blog post announcing the 'Support for editing repeats': https://blogs.esri.com/esri/arcgis/2017/09/21/what-is-new-in-survey123-for-arcgis-v-2-4-september-20...

 

From the published survey, we are successfully sending survey results to the feature service and from the repeats block to the related feature class.  Images captured in the repeats block field are, as expected, saved as attachments to the features in the related feature class.  Everything as expected so far.

 

On the back end we have a web app that is used to view the images that were captured in the repeats block (now attachments to related features to the main survey feature), and then it is used to update values in the text and select_ attribute fields in the related features.

 

Back to Survey123, we do a refresh, and as expected attributes in the repeats block are refreshed with values updated by the web app.  Also, as expected, the picture attachments do not come back to the repeats block because the blog post clearly describes this functionality is not presently available.  That is fine.

 

However, in Survey123, from the Inbox, we then add a new record to the repeats block and capture an image.  When the survey is submitted and sent to the feature service, a new related feature is created, as expected, and the text attributes have values supplied in the survey, but the new related feature does not contain the image as an attachment as we would have expected.

 

It is clear in the blog post that a refresh will not bring picture attachments back to the repeats block in the Inbox.  However, when editing the survey from the Inbox and capturing a new image in the repeats block, shouldn't Survey123 be creating an attachment from the new repeats record when the survey is sent back to the feature service?  We did try amending the value in bind::esri:parameters to ‘query allowUpdates allowAdds’, but that did not seem to help.

Thanks! @

0 Kudos
11 Replies
JamesTedrick
Esri Esteemed Contributor

Hi Robert,

I'm able to successfully submit additional repeats and their images using Survey123 in a test survey.  Could you share your XLSForm so that I could test with it?

0 Kudos
RobertMarros
Frequent Contributor

James,

When you say you are successful in submitting the additional repeats and their images using Survey123, are you doing so from a survey that was already submitted once and then reopened from the Inbox to submit? If so, are those images available in the feature service? We have no problem taking a picture and submitting the survey, the issue is we are unable to see the comments or the attachments in the feature service. 

I don’t mind sending you our survey but I would prefer to not have it be available to the public. Can I send it to a personal email address?

Thanks for your assistance!!

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Robert,

Correct, my testing procedure was:

1) Publish a survey that had an image in the repeat and allowAdds (see attached).

2) Submit a record with 1 repeat

3) Refresh the inbox to load the submitted record into the inbox

4) Open from the inbox

5) Add 2 repeats to the record, each with an image

Viewing the features in ArcGIS Online, there were 3 records in the repeat; each had the attachment expected.

Please feel free to e-mail me at jtedrick @ Esri.com

RobertMarros
Frequent Contributor

Thanks James. I noticed that you are using allowAdds in addition to the allowUpdates. Let me try adding the allowAdds expression to see if that works. 

0 Kudos
JeffPuuri1
Emerging Contributor

Hi James,

I am actually working on this same issue as well.  What happens on your end if you add a query to your bind::esri:parameters so that it now looks like this: query allowAdds=true allowUpdates=true, and then follow your testing procedure?

 

Without query in the parameter list, in your testing procedure after step 3, you do not see the previously submitted repeat record, correct?  In our workflow, we would like to see the previously submitted repeats records, fully understanding that we would not see the previously submitted image, but would be able to see the other input fields which is important context for our workflow.

 

What we are finding is that when prepending query to the parameter list, and following your testing procedure, after step 5 we can see the additional related records in ArcGIS Online with the attribute fields filled in, but the Photos and Files column has 'Add' instead of 'Show' like we see for the attachment submitted during original survey submission at step 2.

JamesTedrick
Esri Esteemed Contributor

Hi Jeff,

Thanks - I was able to duplicate the behavior you described with the setup you specified and have filed an issue.

RobertMarros
Frequent Contributor

Hey James,

Do you have any idea or time table of when this issue could be resolved? Does it seem like a fundamental issue or is it something that could be addressed? 

Thanks!  

0 Kudos
RobertMarros
Frequent Contributor

Hey James,

Sorry to bother you again but is there any chance you could provide some more feedback regarding this issue? Is this something that could be available as a fix, or implementation, in the next version of Survey123, or is this something that has the potential to be a long term issue? Just curious since we have a Pilot Project planned in the next month and would like to know if we need to think of a Plan B due to this issue.

Thanks! 

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Robert,

Given that we've been able to replicate the problem, we need to assess what correcting it will entail.  It is not likely to be addressed by our next release, which is under development, but we will see if it can be slotted into the release after (tentatively in May).

0 Kudos