Deny "Anonymous Editors" Any Editing Rights

[TerryIffland]

Is there a way to deny "anonymous editors" from being able to update existing features or create new features?  I know this sounds strange, but I have a case where my organization is publishing some maps for public viewing, but we also using feature layers for Survey123. 

I've come across a use case where after a user has signed on and downloaded the Form for Survey123 it is kept locally on the user's machine. The next time they open Survey123, they are not forced to log on.  This person then becomes an anonymous editor. I don't want them to be able to update anything unless they have logged in, but I don't see this as an option in AGOL.  I only see the options to do "The same as signed in editors", or "Only add new features...". 

The user's ID and email address are captured behind the scenes as part of the form. Making those values required fields is not really an option since the data entry fields are not provided to the user, and I don't want to ask the user to enter that data.  I would be OK if there was a way to check if that data is available when the form opens and block the user from accessing the form until they sign in.

Since this issue came up while using Survey123 with ArcGIS Online, and I will cross-post a question in the ArcGIS Online community.

[IsmaelChivite]

Hi Terry. Once an ArcGIS Online Feature Service is made public, you cannot prevent anonymous users from editing the information, unless you block editing on the feature service for everyone. 

Tentatively, in the December update of ArcGIS Online a new feature will be implemented allowing you to create read-only views of Feature Services. This would be useful when you want to keep the editable feature service private, and the data available for everyone to see...  Coincidentally the Survey123 team will be the first to implement this feature so I guess you just got lucky    We are doing our best to get this feature into Survey123 before the end of the year, but if we miss the December release we want to make it available in early 2017. Realistically, our main goal with Survey123 is first to resolve the problem where a group of people needs to capture data, and a different group (without edit privileges) needs to view the results of the survey (Data and Analyze tabs in survey123.arcgis.com). In any event, the essential foundation to solve the problem you are facing will be ready.

Here are the basics of how I would see this working for you:

- First you will publish a survey as usual (must be a NEW survey)

- Second, you will go to the Collaborate tab in survey123.arcgis.com as usual.

- This time you will have a chance to share with Groups that will submit data (as usual) and also have a new option to additionally share with Groups that will be able to see the Data and Analyze tabs.  If you choose to share with these Groups a new Feature Service View will be created under your My Contents, which you will be able to manually share with everyone. This Public Feature Service view will have  editing capabilities disabled.  The trick here is that the Feature Service used by the Survey123 app will be secured, always forcing users to login.

It is still a bit early to say exactly how things will work, but as you can see we are trying to resolve the problem. In the meantime, I suggest you ask people using the Survey123 app not to log out of it, so the editor tracking info is always sent to the feature service (even if shared publicly).  You cannot enforce it, but you can always ask...

[TerryIffland · Accepted solution]

Thanks for the response.  I knew it may not be possible, but I thought I'd ask.

Interesting thoughts about the ability to set up 2 types of users - editors and consumers.  Protects the data while providing access to whole new group of people to whom you might want to provide information.

[EricAnderson14]

I had a similar question to this. What I have done to resolve this issue is I created  and published our original map to the portal and tuned the resulting ‘Web Map’. The 'Web Map' was not placed on our 'Featured Maps and Apps' group.  Once the ‘Web map’ was set up to meet the needs of the ‘Editing’ users, we then took that map and shared it as a ‘Web App’. In the ‘Web App’ that we created, we omitted the ‘Edit’ Widget from the ‘Web App’. We DID share the 'Web App' to the 'Featured Maps and Apps' group. I found that any of the changes that are made on the Portal ‘Web Map’, were reflected on the ‘Web App’ as long as the ‘Web App’ version was ‘Refreshed’ after changes were made to the ‘Web Map’.

Hopefully this information helps!

Eric Anderson

[IsmaelChivite]

A quick update on this:

• In ArcGIS Online, you can now disable updates and deletes on feature services. This allows you to configure the security of your survey so people can only add new records.  This may be useful for you.
• All these  security settings are  changed in the Feature Service or Hosted Feature Service View Page  Details.

[EricAnderson14]

In our particular implementation, Anonymous users should not be able to ‘Add’ features either. I tried setting the ‘Feature Layers (Hosted) Settings’ so that ‘Only update feature attributes’ was selected, basically declining the ‘Add’ functionality for anyone. In the section where the access where ‘Anonymous’ users is set, it was set so that Anonymous users could only ‘Add’ new features, hoping that this combination meant ‘Anonymous’ users could not edit or add. Unfortunately, despite trying these settings in our Federated Portal environment running ArcGIS portal V 10.5, we were not able to prevent an Anonymous user from editing a map’s attributes.  

Eric Lynn Anderson

[IsmaelChivite]

Hi Eric.

 I would recommend you have a look at the Create hosted feature layer views—ArcGIS Online Help | ArcGIS  help topic.

 You should be able to create a new Hosted Feature Layer View for anonymous users on which all editing capabilties will be disabled.  Survey123 would continue using the Feature Service with different security settings (to enable Adds, Updates, or Adds&Updates).

[EricAnderson14]

Ahh, there is so much to learn about ArcGIS. It turns out I was using a 'Feature Layer (Hosted)' without realizing that this feature layer was 'Hosted'.

Thanks for the insight.

Eric