Overwrite Existing Services Without Changing Ownership

[TigerWoulds]

Currently, we are using a Federated ArcGIS Enterprise 10.7.1 environment. We have many people working on a project with multiple services.

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

1. An Administrator needs to go in and change service ownership

2. We create a psedo-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.

What we would like to see is the ability for Creators to overwrite any services, without needing admin privileges or being the service owner.

This functionality existed for Publisher user types in our 10.5 standalone ArcGIS Server. For example, a Publisher could overwrite any service regardless of who 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.