Share same feature layer with different editing permissions?

[ChaimSchwartzIroads]

Is there any way/work around to share the same feature layer with certain users (that are "editors") as view-only, and with other viewers as editable? 

I'm aware of the following:

1. Hosted layer views. Irrelevant because (1) in my case we have referenced services and (2) that still ends up with two different end-points. 
2. User types and roles: Naturally, a user with a "viewer type/role would only be able to view that feature layer, however in my case, I need certain "editors" to be able to edit certain layers, and only view others. 

It seems like this used to be possible in past versions of arcgis portal, by using designated groups with update capability, but this isn't supported anymore, or perhaps only for hosted feature layers:

https://www.esri.com/arcgis-blog/products/arcgis-online/sharing-collaboration/enable-colleagues-to-u...

https://doc.arcgis.com/en/arcgis-online/share-maps/create-groups.htm#ESRI_SECTION1_12B3CD7ADAF843DB9... 

https://community.esri.com/t5/arcgis-online-questions/editing-permissions-by-groups/td-p/155954

[Scott_Tansley · Accepted solution]

Hey, to the best of my knowledge this has never been available for referenced services.  We’ve always created multiple nap image layers, with the appropriate capabilities and permissions set on each service.  So one has feature access with edit in and an edit group.  One has feature access with select  in a view group.

its inefficient in so many ways but the only option if not hosted. 

[Scott_Tansley]

I’m never sure if we should share products outside of Esri’s own.  But I have used this approach in the past:  https://www.esri.com/en-us/arcgis-marketplace/listing/products/414b815740f94a88b5fc8779c2cad2dc 

[ChaimSchwartzIroads]

Thank you @Scott_Tansley 

Unfortunately, when you see a dedicated product, that usually confirms there is no viable work around:)

So I also went down the path of publishing separate map services, however I then encountered this bug which makes this approach even trickier. 

Anyways, thank you again.

Chaim

[Scott_Tansley]

Ouch, I've read the provided link.  I've seen a couple of issues with the developer edition, but I'm going to be straight up and say that my 'value' is in the bit between the operating system and the APIs.  When it gets into the 'app space' then there are some far more qualified people than I.  Sorry, I'm going to sit that one out.  

I can say the Con Terra solution would prevent that from happening, as it actively hides the layers the user is not allowed to see.  Not only does it provide advanced security, but saves time/stress on solving these sorts of issues, saves time on publishing/maintaining multiple services and it reduces the need for cloud/IaaS resources to support the multiple web services and their instances...  Frankly, I think it pays for itself in a short period of time.

[MatthiasKl]

We are facing the same problem. Right now, our solution looks like this:

• We duplicate the webmaps. One for write access and one for read access.
• In the read version, we only include the map image layer, which by design does not allow editing.
• We create groups to control the access permissions for the different webmaps

Admittedly, this approach is somewhat cumbersome and not without its limitations. For example, the "read" webmaps cannot be taken offline.

We have been using the old security manager in our old deployment for many years. (which is basically a server object interceptor extension). The problem is that the new security.manager (the product is now called security.manager NEXT) has to be configured via JSON files, which is also very cumbersome. The advantage is that you can control access to ArcGIS services in a fine-grained way e.g. to control access and editing permissions to single layers within a feature service, only certain features or fields within a layer. Unfortunately, the access control system in Portal for ArcGIS does not yet really cover these use cases that constantly occur in our daily business.