Permit changing ownership of items shared with Shared Update groups

[PeterKnoop]

When a user is changing ownership of an item, they should be able to do so, regardless of whether the item is shared with a Shared Update group or not. As with regular groups, if the recipient is not a member of a Shared Update group with which an item is currently shared, then changing ownership should fail with a similar error.

We have thousands of users in our org. They all have the privilege that enables them to create Shared Update groups and to transfer ownership of items; they are the ones that know what is going on, not the ArcGIS Online Administrators, so expecting admins to handle these sort of things does not scale.

Many of our users are working on work collaborative projects for which all members of the collaboration have equal responsibility (the differences between being an owner of an item and having access as a member of a Shared Update group is a related problem.) They use Shared Update groups to work collaboratively.

As people move off of these collaborative projects or move on from the organization, it is important that they can be off-boarded quickly and easily. That currently involves having to transfer ownership of relevant content to others remaining in the collaboration. Again, it is the users who know what needs to happen, so it does not scale to get Administrators involved. (It would be great if groups could own content too, so that this kind of ownership transfer was not always needed, see Allow Organization and/or Groups to own data in AGOL and Enterprise.)

It is un-intuitive and time consuming to perform the workaround of having the original owner un-share items from Shared Update groups, transfer ownership, and then have the new owner re-share items to the same Shared Update groups. 

This specific Idea has come up before, as part of broader Ideas, so I wanted to explicitly separate it out for consideration. For example, Enable Content Manager role by improving/fixing item sharing options and interfaces (see point #2), and Improve Groups where members can update all items and documentation.

[Melinda_Kernik]

I very strongly support this idea.  We also have staff and students working on long-term research projects and exhibits who use shared update groups.  If a student graduates or staff member leaves, they need to transfer ownership of the content that they have created to someone else in the group.  In order to transfer ownership though, the item has to be removed from the shared update group first. This process is unintuitive and confusing (especially because the new owner has to know to add the item back into the group). It would be very useful to be able to transfer ownership of items from one group member to another without having to remove them from the shared update group first! 

[WilliamTarpai]

Thank you @PeterKnoop for not only the extra details, but for adding to the value of this community.

[ClaireGibbs1]

Any update on this for when we can expect an update for blocked migration to a new owner. I have to do this with thousands of data. I am unable to due to the blocking of group. My does this exist and how to permanently remove this setting.

[AnthonyJonesRSK]

Hi all, I came across this idea as we have a number of users who need new accounts due to single sign on changes and when using the transfer member option to move content from their old to new accounts I found a number of items failed to move. This turned out to be because the items were in groups with shared update. The frustration is that the failed items remain against the old account but the tool removes the item folders they were in so you lose any organisation that had been applied.

I decided to do some testing to see if this can be avoided and found that some items in shared update groups did transfer without issue. Initially confused as to why this suddenly worked i found that if the group has the setting "Who can contribute content?" set to "Group owners and managers" and you have the users the content being transferred between set as group managers the transfer bizarrely works. I've no idea why this is the case but thought I'd mention it as it may be easier to set up your shared update groups in this way and then transferring content can be done much more easily without the need to unshare and reshare the data. 

This doesn't resolve all the points made in Peter's original post but hopefully it proves useful. Cheers

[WilliamTarpai]

It is amazing how things happen when we are able to collaborate....  Today I have been in contact with colleagues in Bomet County, Kenya as they reached out to several local high schools, providing computer equipment that will hopefully bring new users into our community and community discussions.

Helping students moving from finding out about ESRI software and tools on computers provided to their schools to being able to become regular contributors to this community is of course, a long process.  So I'm sure we'll be checking back next year to see how development may be happening in the regions along the coast line of Lake Victoria....