The primary idea here is to address item sharing inconsistencies and make it operationally feasible for AGOL/portal admins to delegate content management responsibilities to other members. The methodology we currently use in our agency of 2800 people is described at the bottom of this post.
As it stands, most of the necessary capabilities exist, but a few key constraints limit how AGOL/portal items can be managed within an enterprise, and inconsistencies confuse and discourage users. A few tweaks would go a long way in making AGOL work for organizations that have multiple business units and/or have custom content management roles. Following are some related needs/issues, and ideas for addressing them.
- When reassigning ownership of an item, the list used to choose the destination folder is empty when the person reassigning the item has “Reassign content” privileges but not “View all” privileges. They don’t even see their own folders listed when transferring content to themselves. This needs to be fixed. Content managers that have “reassign content” privileges should be able to reassign content shared with them*, without it also being a requirement that they can see (and reassign) ALL of the organization’s private content. In other words, they just need to see the list of a member’s folders, and not necessarily all of the content in them.
- Enable ownership to be reassigned for items shared with a group that has the “update capability” (aka update all items) option enabled. At present, an item can only be reassigned if sharing with that type of group is first dropped. Needing to drop then reassign this sharing wastes time and is prone to errors, and prohibits custom roles with the “reassign content” admin privilege from reassigning these items (there’s no way for them to first un-share the item with the group – see #5 below).
- For members with “reassign content” privileges, display a “Reassign” button on the pages that list a group’s content, just as it exists on the Contents page, so all selected items can be reassigned at one time. This will help when reassigning items with dependencies (feature layer views, etc).
- Combine the “Access” and “Access and update capabilities” sharing lists into one dialog box. List the update groups at the end, or preferably, in the dialog boxes, do away with the “update capability” group designation entirely. Most users aren’t familiar with the terms “update capabilities” (the terms aren’t even used when configuring a group) or care about the distinction anyway, and it creates lots of confusion.
- Allow members with “reassign content” privileges to share & un-share the items they can view (but do not necessarily own) with groups (or at least the groups that they own or are group managers for). In theory, they could transfer item ownership to themselves and change the sharing anyway, so the security isn’t any different. This could be accomplished by displaying a “Share” button on the pages that list a group’s content. This would:
- Fix the conundrum whereby content managers can’t reassign items shared with “update capability” groups. At present, non-Admins that have “reassign content” privileges can only change sharing by using the “Share” button on the item details page, but that doesn’t let them share or un-share the item with groups that have “update capabilities” (aka update all items) enabled.
- More fully support the notation of having content managers (rather than full admins) within an organization who have responsibilities for reviewing and sharing content for a specific business unit or subject area.
* Our agency uses a methodology (similar to Esri’s recommended practice for managing authoritative content) whereby most members can create content, then share it with topic-based “staging” (aka review) groups for review by a topic owner (aka a Web Coordinator who manages content for a program area). Once QC’d, the topic owner takes ownership of the content and shares it with the public. The item is also then shared with a “maintenance” group that allows all members of the group (including the original content creator) to update/maintain the item. The structure works well and enables content to be managed by a team, and ensures that it is not orphaned when someone leaves. However, it is difficult to implement operationally because the constraints/bugs listed above require workarounds that are often difficult for content managers to navigate.