I would like to discuss an issue that is leaving us stumped on how to deal with it. Let me setup the scenario and use our water network as an example. We have one group (Group A) that is responsible for managing the water network and ensuring its integrity. We have various other groups that perform inspections. Group B performs Hydrant Inspections, Group C performs valve inspections. Logic would dictate that you have a relationship between the water network and this inspection data. e.g. Hydrants->Hydrant Inspection, Valve->Valve Inspection
In the past we were able to get away with database permissions setup where Group A had full edit permissions to the water network. Group B would have read permissions on the water network and edit on the Hydrant Inspection data. This worked fairly well. This even worked to some level on Feature Layers/Services. At 3.x ESRI got more aggressive and required that anyone with edit permissions to any featureclass/table in a relationship tree required the exact same permissions to all related objects. Services fail to publish if you don't have permissions set this way. What is the result of this? Now those inspectors (Groups B and C) have full editing access to the entire water network.
Now when we are publishing feature services and using tools like Experience Builder and Field Maps, we are unable to restrict the inspectors (Groups B and C) from making inadvertent edits to the water network which can then affect the integrity of that network. This to me is a fundamental flaw in the permissions and tools implementation around who is allowed to edit what.
How are other organizations handling this problem so users don't edit data they are not supposed to?
NOTE: In order to add an inspection to a location using out of the box tools, you need to include the features. In order to add related records to those features, you have no choice but to also enable editing on the feature as well.
hi Kevin,
Similar enterprise issues with esri datasets, cascading privileges that do not work as hoped when different department/divisions are responsible for child feature classes.
and requirements for single source geodatabases, topological relationships.
Have you waded through the esri docs to see if these other options could work for you?
joins
vs
relates
vs
relationship classes