I am boggled by this--what is the purpose of the View/Edit toggles in the Pop-Up configuration, if not to constrain which fields are editable? Could it really be true that anyone who can see the [hosted] Feature Service can also edit the Feature Service?

Actually you can do this, but you have to ceate a second (no edit) map.

- Open the editable map and go to configure the pop-up- Uncheck the Edit toggle for each field you want read-only- Do a "save-as" of the map and call it something different than the editable map name- Share this saved 'no-edit' map with a new group and add the read-only users to this new group(Editors will view and edit the original editable map in another group)- The edits will be seen on the read-only map but the users in the read only group/map cannot edit/update.

Thank you for the response! I tested exactly the workflow you recommend, but a browser-based user in the "read-only" map could still edit. Can you confirm that this definitely worked in your environment?

Yes it works, but I forgot that the method I described does not prevent users of the Read Only map from placing a new feature -- only prevents attribute updates to existing features.

However, there is another method...Open the Read Only map and click 'Disable Editing' --found 2 places below the 'Configure Pop-up' option on the feature drop down menu. This will disable feature placement, feature movement and attribute updates. Even with this, a savvy user could still re-eable editing using this same button. For a truly read-only view, You could choose disable editing and then make a Web App (Share>Make Web Application) and choose something like the 'Legend' template. Then share the app with the Read Only Group.

Thanks, again, for the suggestion. It seems though, that there can only be one definition for a hosted service. So if you disable editing for one web map, then that same service in a different map is also edit-disabled. Is that your experience as well?

It works on my end. You stated that "there can only be one definition for a hosted service"...You are not disabling editing on the service in the service properties, but rather within the web map properties.So you save the map with editing enabled. Next disable editing and then 'Save as' the web map (not the service itself) with a different name.

It works on my end. You stated that "there can only be one definition for a hosted service"...You are not disabling editing on the service in the service properties, but rather within the web map properties.So you save the map with editing enabled. Next disable editing and then 'Save as' the web map (not the service itself) with a different name.

[ATTACH=CONFIG]31466[/ATTACH]

It is not really "working on your end". If your hosted feature service is set to editable and is shared publicly Anybody can find and edit your hosted feature service by adding it to their map and setting up their map to edit it!

If you have a road closure map and you think just because the map the public sees has editing disabled that the road closure service is safe. Then all the sudden all your roads are set to closed because some one found your service and started playing around with it. Until ESRI allows editing publics shared hosted feature services for users of a specific group, your service will never be safe from pranksters.

Even if you do not allow the Public to view your services, this still creates a problem within your own organization. We have many overlapping interests where Group A needs to edit something that Group B should only view. This seems to hinder both Organization and Public levels of publication.

Data creators using Collector aren't allowed to edit the status of a certain attribute field. So on their map, I configure the popup to not have that field.

The Data editors/reviewers have that attribute field in their popup so they can update the status of said point.

I had to create three web maps for this project. WebMap 1 for data creatorsWebMap 2 for data editors/reivewersWebMap 3 read only web map showing the status as the editors chose, and used a filter to show only the approved status values.WebApplication - linked to WebMap3.

Viewers don't get WebMaps, they should only get WebApps (ESRI Basic Viewer) with editing option disabled. Those users should belong to a group where the WebMap and WebApp are only shared with those groups respectively.

This is how we edit data in the field and let other users "see it" without being able to edit it.

The key is everything has to be shared within your organization or group.

Leo, thanks for the feedback. The testing I have done suggests that the methods you describe can be defeated by a clever user in the "read-only" group. Have you shown a different result? And, are you using AGOL hosted services, or your own ArcGIS for Server services? Thanks again!

Leo, thanks for the feedback. The testing I have done suggests that the methods you describe can be defeated by a clever user in the "read-only" group.

Can you elaborate?

Didn't see the second part...

Well, I "can" use my own ArcGIS Server for services, but this application was for someone else, so they wanted it in the AGOL hosted services because they wanted to be able to update the FGDB schema, edit the map settings, etc...

Are you saying that if you publish a WebMap with editing disabled, and add that WeMap to say the ESRI Basic Viewer and disable the editor option there and share those two items with a specific group that the users in that group can still edit the feature service?

They log in to Arcgis.com, click Groups, enter their group, and instead of going to your application, they open the web map you used to create it. They have to be granted permission to see it, or they can't use the application. And they can edit the features in the web map.

But you can click the drop down arrow to the right of the layer in that web map and choose disable editing, save the map, and then they can't edit it, right?

Are you saying that a user can change that setting if they don't own the content? Really?

I just demo'd our app today and we had the customer login with their account and they couldn't get access to the layer configuration properties because I published the content under my login, I was the owner of the map, feature service and web app. I had to change ownership of the content to their login in order for them to be able to do things like configure the popup in the web map.

But you can click the drop down arrow to the right of the layer in that web map and choose disable editing, save the map, and then they can't edit it, right?

Are you saying that a user can change that setting if they don't own the content? Really?

Yes. The read-only user, who owns nothing and has only user credentials, can go into the read-only group, and open the web map with the "editing disabled" layer, and click the drop down arrow, and Enable Editing.

And, as a sidebar, I share your incredulity, and more than anything am hoping to be corrected. I look forward to seeing if you can replicate my experience.

I need to find a regular user to test this with. But, I'm being told here that what you experience is currently normal.

However, I swear that yesterday when I was looking at my content, through a regular user's login, they couldn't change anything. Maybe I was wrong.

If it is true that regular AGOL users can re-enable editing on a web map that they don't own, then that is a problem. All the more reason to roll your own web editng maps.

I would have thought the fact that users who don't own content shouldn't get access to change map settings of someone else's content would have been the norm. That would also fix the problem.

However, what if... you create a lame duck user account. That user saves a copy of your web editing map. Then you assign this map created by the lame duck user to a web app (ESRI Basic Viewer) and let your other read only users see that web app?

Thanks for the effort--I don't think I am arriving at your intended content via the link; it takes me to the generic blog page which doesn't appear to have anything pertinent to this topic. But I would like to see it--will you resend, or screen shot, or copy/paste?Thanks again!

I often have that problem too--a link to a blog entry goes to the main page instead. A second try will often work. Leo's link works for me. The blog post was on February 11th, and is now on page two if you go to the main page.

Anyhow, the only possibly relevant thing I see in the post is this:

Custom RolesThe existing organizational roles of Administrator, Publisher, and User are being complemented by the addition of custom roles. Custom roles provide a more granular way to control member privileges, enabling you to tailor unique roles to suit your needs.

Leo, is that what you were talking about?

I haven't used AGOL beyond pulling public content into a map, so I can't help on the problem.