Allow Organization and/or Groups to own data in AGOL and Enterprise

[DerekWaggenspack]

I believe that an Organization or a Groups should be able to own content.  This would alleviate a vast majority of overhead when people who own data/maps/apps leave an organization.  Instead of having to either create headless users [wasting at least one Named User seat] that would have the overhead of transferring data under their umbrella and having to share this common password or transfer all that data to someone else so that the user can be removed, you would simply have to.. remove the user.  Members of the group owning the data would be able add, update, and remove items in that ownership group.

For groups to own data, here are some thoughts on possibly implementing it. 

In the group creation, require that the who can change content in the group be all members of the group. 

Add a checkbox to group creation "Allow group to own content".  If checked, it could create a named user in the background in the group's name [that doesn't take up an actual seat]. 

From there, the appropriate members could update the maps/apps/layers owned by the Group, and data would then be shared out via a non-data-owning group.

[SamPalmer]

This would be great! We end up spending a lot of time helping users at our org transfer content when they are leaving. With group ownership of items, the overhead of transferring content would really be reduced.

[PeterKnoop]

I think a key component of this Idea of group-ownership is that all members of the group have equal rights and privileges when working with content in the group. One of the shortcomings of Shared Update groups is that there are still things only the individual owning a content item can do.

[PatIampietro]

This would greatly improve collaboration in our org. As @PeterKnoop pointed out, "Shared Update" groups are really only a partial solution, as each content item shared with the group still belongs to a  single member (often multiple different members across all shared content in the group), which limits what the other members can do to/with it.  And as @DerekWaggenspack pointed out, content management when members leave an org would also be greatly simplified if Groups and Orgs could own data.

We use Groups a lot for courses, and having the content belong to the course or group project within the course would simplify its persistence after the course is over (and even after the students graduate), making it easy to use in future offerings of the same course (and others).

At the risk of combining Ideas, I suggest that this functionality be implemented so that enabling it does not require Admin or special privileges, and should be changeable after group creation (both of which should be the case for designating "shared update" status, but currently are not).