Latest Contributions by BillSimper

Since 2018 I've been using Survey123's custom URL scheme to launch Survey123 forms from other Survey123 forms to create a hierarchy of parent-child forms/data layers. This allows me to make a complicated system of forms modular and avoids some problems that arise using Repeats (the major one back in the day was that you couldn't do nested repeats admittedly having since been changed). When doing this I had been able to successfully pass data from multiple fields in parent forms to child forms using the well known format (e.g. arcgis-survey123://?itemID=36ff9e8c13e042a58cfce4ad87f55d19&field:surname=Klauser) as described here. Specifically I've been using the calculation parameter of XLSFORM to assemble the URL and create the link as a text question type to dynamically pass field values (text and numeric data types). Here's a typical example using the concat function: concat('<a href="arcgis-survey123://?itemID=XXXXXXXXXXXXXXXXXXXXXXXXX&field:parent_uuid=',${survey_uuid}, '&field:individual_id=', ${individual_id}, '&field:alive_dead=', ${alive_dead}, '&field:sex=',${sex}, '">Click here to open a CHILD form.</a>') However, I'm now seeing this failing in my forms. The correct Survey123 form will launch when the link is clicked, but no survey data is being passed. After failing to get this to work for one form a user reported a problem with, I decided to check out other forms that have been working-- they don't work now either. Then I started trying older versions of Survey123 field app (I keep old versions installed on my desktop for this purpose). Long story short, the URL scheme's worked as expected up to version 3.2. Version 3.5 and 3.7 are failing. Most likely this wasn't reported earlier since most of the forms I use this functionality with get used in the spring and version 3.5 came out last summer. However I really need this working for upcoming spring surveys. I should mention that I use the field app almost exclusively-- so this all pertains to field app, not sure if web app showing the same problem. Has there been some kind of change to the way Survey123's URL scheme works? Thanks! ... View more

Here's a typical situation. I have a hosted feature layer set to allow editing (add, update and delete). I add it to a web map with full editing control and save the web map, going to the trouble of naming the map, adding tags, adjusting sharing, setting up cartography, table of contents, labelling. The web map is intended for use by end users to edit their own data, including deleting records. I try it out myself and it works.  I add some records, typically through Survey123, to make some final adjustments to a form in development. These adjustments within Survey123 don't involve any schema changes or deletion/recreation of the original HFL, merely form-internal 'cosmetic' or form-logic changes. By the time I'm done, I want to delete the test records and now when I click on the records, the option to 'edit' is no longer part of the pop-up. Typically this is in a map/browser window that's been open the entire time I've been testing my form, i.e. 30 mins to couple of hours. Reloading the page, re-opening from Contents, logging out and back in, and restarting in a new browser window don't fix the problem.  Why does this ability 'go away'? As I mentioned, the layer is configured to allow editing by the users, and in addition I'm the owner of the all of the components of the web map, having assembled the entire set-up. Editing seems to still function-- I can toggle the Edit tab/button and thereby add points and it looks like I can still edit field values as well. But I and my users need the ability to delete individual records. As far as I'm aware, this is only possible via clicking on the feature in a web map, not in the attribute table or in the Data tab of the HFL. I know that it's possible to do this by going the the HFL item description page and opening it into another web map with full editing control. However, I need to be able to set up reliable QA/QC maps for our end users and not have them constantly creating temporary utility maps (which is well beyond the level of experience a typical end user has or should be expected to have). I've encountered this problem sporadically and tended to attribute it to some configuration mistake I've made, but today it's happened several times in a row over the course of a day, and I'm confident I'm not doing anything 'wrong' (that I'm aware of) and I use AGOL on a daily basis, so I'm not a novice user. It's an incredible waste of time to have to start from scratch to set up a map, not to mention the massive confusion for the end users. Can someone shed some light on this? On a related note, what exactly is 'full editing control' and why isn't this the default condition for any HFL that has been configured to allow editing? If it confers important additional capabilities, how can this be specified when adding a layer from the web to an existing web map-- as far as I know it's only possible to enable this for a single layer when adding to a brand new web map from the HFL's item description page. And finally, am I missing something or is there a better way to delete features than highlighting them in a web map and using the delete button in a pop-up? Even when this is working it's EXTREMELY convoluted, as you have to find the record in the attribute table, then zoom your map to it, click on the feature, toggle through any coincident features (very confusing to end users and arises fairly often), then when you've found it, click on 'edit this feature' (IF this is working properly), then you may have to select the feature again, then you can click the button to delete. Ideally, a user should be able to delete a selected record in the attribute table (just like they can in ArcMap) AND at in the data view for that HFL (although that really requires more experience than our end users are ever likely to have). Thanks in advance for any help on this topic! ... View more

Hello, 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-available-28 ). 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?  Thanks! ... View more