I wanted to check on the status of a bug (in Survey123 and/or ArcGIS Online) which prevents the submission of records that contain attachments when the Settings on the Hosted Feature Layer or View are set to "Editors can only see their own features (requires tracking)" and/or "Editors can only edit their own features (requires tracking)". The bug has been present since mid-May 2018 (it's referenced by a comment by BArmstrong in this post https://community.esri.com/groups/survey123/blog/2018/05/16/minor-update-to-the-survey123-field-app-... ). Prior to that time, the feature had been working as expected.
Our use case is we'd like to share certain Survey123 data forms to external collaborators (with named accounts) to allow them to submit data but need to restrict viewing permission so as to hide potentially sensitive information being submitted to the same dataset by our internal staff. It's also handy for a QAQC editing workflow to restrict to 'editors only' in cases when there are many contributors and many submitted records that have to be sifted through by the end user during QA.
A related (but distinct) problem that is also still occurring is that submission of records containing attachments fails when the Hosted Feature Layer (or View) settings are set to "Add features" and "Editor can't see any features, even those they add." This problem (originally referenced here: Cannot attach images in Public Survey). Although the original post associates this problem with public surveys (which is where these settings are usually used), it occurs for both public and private surveys. In this case we have a need to prevent the exposure of potentially sensitive information submitted by the public (i.e. not through named user accounts) from other anonymous submitters, so having this functionality is a critical need for implementing numerous planned public forms.
Both of these problems only occur when records contain attachments. However the ability to submit with attachments is a critical requirement for these forms. Any idea when we can expect a fix for these problems?
Hi Bill. Thanks for your detailed explanation.
We are actively working on these two issues.
In the next few days we will be releasing a new hot-fix-style update to the Survey123 field app to address situations where the app is not reporting errors when ArcGIS Online prevents the submission of attachments when query capabilities are disabled. This Hot-Fix is simply for the app to properly report the failed submission to the user, so data can be successfully submitted once the query capabilities are reestablished in the target feature layer. For your scenario, this fix is of little help since it still forces you to enable query capabilities, but this fix is important to avoid data loss.
This past Friday we received confirmation from the ArcGIS Online team that the issues preventing the Survey123 app from submitting attachments in the distinct scenarios you describe above have been addressed in our development environment. We will use the next couple of weeks to validate the fix. If the fix is confirmed, it will be made available in the next ArcGIS Online update late in the year.
For clarity, this issue appeared earlier this year when we changed the way Survey123 submits attachments to accommodate a series of reliability issues. After we changed the approach to submit attachments, a series of problems (As described in your original post above) with ArcGIS Online feature services where uncovered. We have been actively working with the ArcGIS Online team to address the issues and we are getting close to resolution.
Our apologies for the delay on having this fixed.
Thanks for the quick reply-- good to know the team is working on it and is into the testing phase.
We are still facing this issue where if a user submits an attachement, it fails. Any developments on this topic?
Here's another variation on the theme of 'attachment problems due to feature layer settings'. In the discussion of one of the problems above (Cannot attach images in Public Survey ), a suggested workaround is to use a View Definition to restrict Features exposed by setting a condition that is always false, such as ObjectID < 0.
I tried this and it works (with attachment) IF the record is submitted through the Survey123 app (I tried it on the Windows app version). However submission fails if the the record (with attachment) is attempted through the browser-based version of S123 (same form). Note that submitting a record using the same form from the browser-version without an attachment works fine.
I'm submitting this just to bring it to your attention-- obviously we want to be able to achieve the desired result without resorting to a work-around. However, if it's looking like a full fix may take months, it'd be great if the work-around could be made to work for the browser version (assuming that's easier to address or more local to S123), since our need for
1) allowing users to attach photos
2) in a form available to 'everyone' while
2) hiding all records from submitters
really exists in the context of
4) needing the form to be run from the browser version of S123, since this is the most universally accessible way for the general public to find and utilize the form.