Sharing to Content to ArcGIS Enterprise, Overwriting shared content

[BarryFosberg]

Bottom Line First:

My goal is to allow anyone in the division with write access to our Enterprise portal (build 10.9) to overwrite a hosted feature class. Share Overwrite only allows users to see their folders. How do I configure share to allow a user to see shared content at the Portal?

I am in Law enforcement. We are using Enterprise in part because we have our own firewall. The workflow for this project includes some involved processes designed to ensure that no one working the project is asked to name a field, attribute, or a feature. Once they have finished at the Arc GIS Pro (2.8) level, they are to overwrite one hosted feature class. The hosted feature informs a web map which then informs several web maps, each one populating a Web App and the apps are displayed to the Department in a storyboard. All of this is fine if I run the process beginning to end.

Should I not be present, I have shared a map project which others in my Group can access and operate. When the time comes to share/overwrite to the portal, only I can see the folder where the features class and the rest are stored.

Every map, app, service, and feature class in the project are shared to the group. The group can edit.

I have looked at Overwrite Feature Services Script Tool for Automating Updates. Has anyone used this for this kind of problem?

Has anyone another or better solution?

[BillFox]

How about delete all features and then append?

[BarryFosberg]

BillFox,

Thanks for the suggestion. We hope to be able to test some ideas in a test environment. Yours should be one of them. 

As of now the plan is to share to any folder, then edit the project hosted feature class with common names and schima features from the non original folder. 

An issue I have had with delete and append is that I do not know what is lost in the time between delete and append. 

In Pro I have seen total loss of downstream definition query copies (need a better term for that) .

The bottom line remains, at the portal, no one sharing features can see into a folder other than theirown. 

[BillFox]

Is using a registered feature class in an enterprise geodatabase an option for you?

[BarryFosberg]

Thanks for this idea. I have very briefly looked at this, and to be honest, do not know enough about it to give you an answer.

Can you add to your suggestion?

[BillFox]

Sure, it would just become the target via a published map service (with the feature access box also checked on during publishing) instead of using a hosted feature class.

You just have to do a few back-end chores first:

Include database instance/database editing security for the user account that is running the windows service that is running ArcGIS Server & Federated Portal.

Register a new connection to your geodatabase from your ArcGIS Server that uses operating system authentication

Create an AD security group for folks that will be viewing/editing that feature class

Add that AD security group to your database instance as a login

Create a database role and map that AD security group (now an instance login) into that new database role

Add that database role to the privilege list of the feature class

Add that windows service user to that AD group

Publish a new service that uses operating system authentication

It is all built for multi-user editing/viewing using versioning options, editor tracking, Web Adaptors, SSL, AD SAML/Single Sign-on, etc.

[tigerwoulds]

Just to note, if you federate your GIS Server with ArcGIS Portal, the security/ownership of services is going to use the Portal security module. So, you're going to run into the same issue with ownership and service visibility, regardless of whether the services are Hosted or Registered.

If you choose not to federate (aka run a stand-alone ArcGIS Server) then I think this will work. But if you are a heavy portal user you now have to manually bring your services into Portal by adding layers by the service URL.

 

[BillFox]

I'm not sure if the full request workflow involves a bunch of spatial joins or other tools creating "New" feature classes, tables, etc. but if it is straight forward data access this option could eliminate the need to overwrite any services because it would be referencing the source feature class(s) instead.

[tigerwoulds]

I'm pretty sure this is the intended design of ArcGIS Portal (and it's a big pita). You can only overwrite services owned by yourself. For example, if I publish a service. Then a week later someone else needs to come and overwrite this, an Admin must first change ownership of the service to the other user in Portal. 

In the past, I've created a pseudo-admin type role in Portal and assigned this role to certain users I trust. They can update ownership of services to whomever. One downside is granting Admin privileges to a user now gives them access to view/edit settings in the GIS Server Manager.

Note: We are running ArcGIS Enterprise and publish mostly services from a SQL Server DB to a federated GIS Server rather than publishing Hosted Services. But I think my points above still apply. Someone please correct me if I'm wrong. 

[BarryFosberg]

You are not the first to make the observation in paragraph 1. Pita is the word. Kinds speaks against the idea of collaboration. 

Your second idea look very interesting, but , well you already addresses its downside. I was thinking of something like a psudo-user. move the project into the PU (could not resist) folder and share the password to those who might run the update when its not me.