I would like to have a map (utilised by a webapp) that caters for more than one use, because the background layers will be the same for all users. The use includes editing, but editors of layer A should not be able to edit (and see) layer B, and vice versa. I can put editors of layer A in one group and editors of layer B in another, but my understanding is that the map (and webapp item) have to be part of both groups for any of the people in the groups to even open the map or webapp.
Is it possible that the same map (and webapp) is used by different groups whereby one group can edit layer A but cannot see (and edit) layer B, and the other group can edit layer B but not see (and edit) layer A?
Perhaps there is a mechanism via views, but would views allow editing?
Hi Hugo Bouckaert,
Maybe a silly question, but why do you want to stick to a single web map? Why not two, i.e. one web map for group A and one for group B?
If you create one 'base web map' with all the background layers that should be visible for all users, you can then create two copies with the relevant editable layers added, one for each group. This will definitely be the easiest way to make sure an editor from group A cannot see or edit the layer for group B and vice versa.
Regarding your question about views:
When you create a feature layer view, a new hosted feature layer item is added to Content. This new layer is a view of the data in the hosted feature layer, which means updates made to the data appear in the hosted feature layer and all of its hosted feature layer views. However, since the view is a separate layer, you can change properties and settings on this item separately from the hosted feature layer from which it is created. For example, you can allow members of your organization to edit the hosted feature layer but share a read-only feature layer view with the public.
Long story short: I think you will need to create 2 separate web maps. But maybe someone else has another solution?
There is a plethora of reasons why not to make two web applications.
This is very noticeable in a large organization and sometimes it is just far more efficient to have One Web App.
Double the product to maintain, double the Change management processes and documents (including docs to maintain), more stuff to, in essence, piss off business (non-GIS and field guys) .. double the 'stuff'. Having one app as the go to is much more efficient in 'SOME' instances. I say some, because it really depends on the business and the ask.
One thing that is Super irritating about ESRI is this mentality of Separating eveything. Spin on a map for the basket of layers.. .then another for this... though it might seem like a good idea to keep maps simple, in big organizations, that fails hard. Business wants integration, insight with rich context...one stop place for larger view to the organization. 100's of web maps doesnt work. There will always be the ask for 'but I want some of what is there and other there in this...
How this is done...
You create multiple ArcGIS Server Services and associate each AD Group Accordingly. Granularity exists. You can have one group only be able to UPDATE and CREATE while another has 'admin' - Update, Query, Create, Delete and another, the view. Or in the Ops case, two layers that they dont want each other to see.
View is easy, you hit the MapServer service instead of the FeatureAccess Service.
all layers can be added in the web map (or layers in App) and you remove any flagging dialog of 'unable to load layer' so that the other group is not aware that they are 'missing' a layer).
As far as the Ops Group A - edit and view a layer that cant see Group B and VisaVersa. is quite easy.
Group be isnt part of Groups As Service... layer fails to load (Controlled at ArcGIS Server Level- OR if you want to go fancy, SOI - server Object Interceptor) , Visa Versa.
For scenarios that I typically go through where as business wants a layer visible to all or a certain group (VIEW (aka Query only) and wants another separate group to be able to 'edit' - create, update and then another group with Create,update and Delete capability...
You have your THREE services (with each of its managed AD groups)... you add the VIEW layer through the MapServer level , you add the editing feature services .. but have the symbology transparent. you remove the layer from the TOC.
If you log in as a viewer, you see the one layer... view the content
If you log in as Group B - you can click on the viewer layer ... but what you are really clicking on with editing ability is the feature (transparent service). You can now edit (based on settings for that service).
We do this quite often.