Overwrite Existing Services Without Changing Ownership

[tigerwoulds]

We are currently running a federated ArcGIS Enterprise 10.7.1 environment (windows on-prem). Our projects are generally multi-user and contains several REST services.

If a user wants to overwrite a service that was not originally published by them, we have two options:

1. An administrator needs to change service ownership to the user looking to overwrite

2. We create a pseudo-admin role and assign the role to specific users who can then overwrite service ownership

One major downside to option 2 is if a user is granted any admin privileges, they now have full administrative access to the GIS Server. For example, they can change the Primary Site Administrator account credentials.

Idea: Allow creators/publishers (or another OOTB role) to overwrite any service, without needing admin privileges or being the service owner

This functionality existed for publisher user types in 10.5 standalone ArcGIS Server. For example, a publisher could overwrite any service regardless of who originally published the service.

[RyanUthoff]

YES!! I agree 100% with this idea. I created an idea to resolve a side effect of this issue. Even if you change ownership to the person republishing it, if they are not members of the group the item is a part in (even if you are an administrator), it unshares the item from the group when republishing. It's very annoying.

https://community.esri.com/t5/arcgis-pro-ideas/do-not-un-share-feature-services-when-re-publishing-i...

[Bark0s]

I too would like to see this role/privilege change.  

Currently the Enterprise documentation note states:

Note:

Only the owner (or administrator) of the item can perform the following actions on the item (not all actions apply to all item types): delete, share, move, change owner, change delete protection, publish, register an app, overwrite data in hosted feature layers, and manage tiles in hosted tile layers. However, members of this shared update group have other administrator types of privileges depending on the item type and the app used to access the item.

I don't quite understand what 'shared update' means if people brought together in the group can't actually update, share, re-publish a service in that group.  It seems a pretty restriction that is a recent addition that wasn't present in a number of previous releases.   

I've had people try to tell me "shared update means you can edit the data" - well, no, what you are describing is editing the data and that's possible without shared update, for field worker roles and others.