nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Najděte více příspěvků označených jako

Accepted answers

All comments

BarryFosberg

You are on to more than the problems with the Agreement.

Having a Common user at the portal is of no value, unless their exists a common log in Pro. That is the ability to store in a common folder at the portal, depends on having a common log in at the desktop.

I have a few ideas left

tigerwoulds

While that's a good solution, you should dig into your ELA with esri for your ArcGIS Enterprise license. The way ours has always been structured is such that every user must use a named user account and 'shared' accounts are not allowed. Even for things like a generic pseudo-admin account set up for the sole purpose of changing service ownership. I talked to our esri account manager about this in the past and they recommended the custom role assigned to specific users.

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.

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

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

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

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

How about delete all features and then append?

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Přihlásit se
Registrovat

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.