Need to be able to Sync replicas a user does not own

[JoeHershman]

Currently replicas can only be synced by the user the created the replica or a portal admin.  It is a common offline workflow to use devices that are shared by multiple field personal.  The size of the replicas can make it impossible to have each user download/register their own copy of the replica.

A setting in replica generation is needed to define it as shared, which would allow other Level 2 portal users to sync that replica. 

Along these lines you should be able to define the user when opening a replica for edit so Editor Tracking uses the logged in user not the user who created the replica

Scott Prindle‌

[ScottPrindle]

Hello Joe,

Thanks for submitting this idea!

Currently, if a secure feature service is accessed and a replica is created, it is owned by the user that was signed in at the time. This is closely tied to the identity of the field worker, which has presented the behavior you've encountered.

However, if a service is unsecured when the replica is created, then there is no identity associated with said replica. This could be a potential workaround if you are able to give it a test.

Could you expand on your use case? Beyond sharing a single device and large data footprints, what other uses would you have for multiple field workers being able to sync the same replica? Could you outline how you envision the workflow panning out if this idea were implemented? Would a replica be created with a set list of users it is shared with, or open for any logged in user to sync?

Please feel free to add any notes you feel may clarify your request.

Thanks,

Scott

[JoeHershman]

Scott..Thanks you for the reply and consideration.

While it is true that having a completely unsecured server would allow allow for any editing of a replica it certainly would be a step backwards in what we are to be trying to achieve with the ArcGIS Enterprise model.  I don't see this as a valid workaround when trying to implement the newest security models and infrastructure of ArcGIS Enterprise.

I would see security working the same may that security is setup in Portal as a whole.  Currently, to define security for data synchronization the portal group model is used.  A service must be shared to any user that needs to synchronize data with that service.  I think it would be very valuable if in the same way when a replica is created a group could be defined that all members of that group could synchronize that replica.  This would allow a good security model for the common scenario of a field crew which has shared resources.  Currently, the workaround being used is to elevate the permissions of the standard Level 2 User which grants too much rights to a standard user. 

I see the advantage in an ownership based model like currently exists.  For certain type of data collection where a greater degree of security is required and for a small work force I believe this appropriate.  But with a large work force having a single named user associated to the replica is a nearly impossible model to implement.  In addition to the general case of a shared laptop there are issues associated to deployment to a large workforce.  In many cases it is not realistic that the field worker themselves does setup of a field machine, this is often done by the IT group when a machine is built out.  Allowing a group to share a replica, would allow this deployment approach

Thanks

-Joe

[ScottPrindle]

Hey Joe,

I don't believe the workaround I provided is a suitable one for a production environment where editor tracking or security are very important. The reason I mentioned this workaround is because it's one way to generate a replica that isn't associated with a logged in user. This would allow you to then secure the service, and continue synchronization with the replica, as long as the user attempting to do so has permission to access the service.

The current replication workflows appear to rely on the identity of the creator pretty heavily, as you've clarified previously. This can be helpful if a single replica might end up on multiple devices, to provide some limitations on who is able to sync that dataset. It seems like the core of your idea is to have the option to create replicas with the intent that they can be used by any named user in a specified Portal group. In this scenario you'd be handling distribution and management of these replicas, but depending on who is working with a device that day, the replica must allow "User A" or "User B" to make edits and sync. This would expand the current functionality to associate the replica with a group, while not opening it up for anyone to use (replicas generated anonymously).

Please let me know if this understanding of your request is incomplete.

Thanks,

Scott

[ScottPrindle]

All,

When voting for this idea, please consider commenting to share how this would fit into your workflows. What are you doing currently to manage identity with your replicas, and how do you envision this idea improving your projects.

Thanks,

Scott

[bryanmay]

Hi Joe,

We may have a similar problem to this one.

Did You ever get a solution?

 Bryan  May

[JoeHershman]

I believe we were able to setup a new user type that gave an additional permission which then allowed for the user to sync without being the owner.  I need to talk with some folks and see what that was exactly (this was two years ago )

[bryanmay]

Thanks Joe,

ESRI Support referred me to this thread.

If I could briefly describe my problem and ask if it sounds similar to yours?

We have a Collector app for 2 users. 

The data is in SQL Server,  there is an enterprise gdb with default version and a child fieldwork version.

When a user downloads the map in Collector a new version is created from the fieldwork version.

The problem is that the new version is only named for the user if the user is an Admin on Portal.

If they are not an admin on portal then an unnamed version is created.

I need the name version for processing.

[JoeHershman]

Hi,

Here is a screen shot of the permissions we gave.  During testing we saw that while the standard Data Editor user could not update the replicas they didn't own, an administrator could.  So we messed around with permissions to see what would allow the editors to do the same and then created a new role for them.

Our field editors don't ever access portal through the web so they are never in there doing things we might normally not want because of these additional rights.

Hope that helps

[bryanmay]

I think that is gonna work!!!

Thanks!!!