Finer Control Over Who Can do What in a Portal Group

[DebbieMurphy]

For Portal groups, we really need more fine-grained control over specifying who could do what within that group - i.e., a set of users who could fully administer the group, a different set that could share items and view (i.e., like read/write), and a set of users who can only view (ie, read-only). You can get part way there by manipulating group properties, who is a member or not, and whether you publish items to a group only or to a group + Public (or the group + Organization).  But these settings are all pretty coarse-grained, and no matter what combination you try, you inevitably end up with some situation you don't want.

Submitted on behalf of my DoD client

[ThomasEdghill]

Thank you for posting this idea Debbie Murphy

If possible, I'd like to understand some more about how this granularity in group permissions would be utilized and why it should be independent of organization-wide permissions. Currently, in Portal for ArcGIS, we expect these types of permissions to be handled through the use of custom roles which define what a user can or cannot do across the entire organization.

Are you able to provide some context into situations where a single user who has a certain set of privileges throughout an organization would be required to have less capabilities within a single group only? This will help to promote the viability of such an idea's implementation.

[DebbieMurphy]

Thanks for the response Tom. I posted this for my client so I will send you their contact info in a private email.

Debbie Murphy

(704) 541.9810 ext.8641

[JTessier]

Hi Tom, 

   It might be easiest to provide a certain scenario to paint the best picture.   Our organization is separated into different geographical regions and each Regional Manager needs to have some autonomy and control of the content they are (and aren't) sharing.  As you note, custom role privileges are portal-wide and thus if a role was setup that had Update all content for example, they could affect all content across the Org.  What they mostly need however is to control who can do what in the Regional Groups they have setup.  For example, they may want a 3 people in the region to contribute to a certain group and all the rest of the folks in that region need to be able to only view this content.  In the Portal at 10.3.1 (and I think beyond) only options for Contributors are: "All Members" or "only group owner."  So if you take the "only group owner" option, you have one person who has to re-share content of the other 2 folks if they want to meet this workflow.  And "re-sharing" is not a real supported workflow for non-built-in admin users (though it looks like it is due to a bug, but that is a different story and bug submission).  In fact the group owner in this situation would need to be part of a custom role that can re-assign ownership (uh-oh Portal-wide privilege!) , change ownership of the item to themselves, share it to the group, and then (hopefully) change ownership back to the other member who created it/maintains it.  Certainly not ideal as we don't want users from one region able to necessarily see or change ownership of the content for other regions.   Option 2:  Allow all members to contribute means that we could not provide that read-only view of the content to other specific members of our region.  Perhaps we could if we shared the group to the entire organization but then that opens up that content to a much wider audience than desired.  Again a situation the Regional Managers don't want.   Finally, it could be suggested that each region needs their own portal but that seems to be a wrong choice for several reasons: As of this writing, portals cannot federate with each other, and even if they could this would be super expensive and overkill for this one seemingly small group control that might be implementable for Groups.

Let me know if you have any more questions.  We banged on Portal privileges for quite awhile trying to see if we could come up with a better solution than one of the above and couldn't.  Thus this idea/request.

Thx, J