ArcGIS API Bug in user groups property?

[MikeKing2]

I was wondering if anyone has had problems listing the groups a user is a member of when that user is member of another organisations groups?  It would appear the whole property is locked and not just the specific group/s owned by the other org.

I am accessing with a simple 

getattr(u, 'groups', default_value) 

where u is an item from the list of user objects.

The full code accesses ArcGIS Online or Portal and pulls down all the user properties for members of our org.  This is all fine until it encounters a user who is member of a group owned by another org.  Then the code will fail at attempting to retrieve the "groups" property for the user.  Since "groups" is instance of arcgis.gis.users which is a class list -  any operation on that entire property generates:

"You do not have permissions to access this resource or perform this operation."

The script is running under my user account which is org admin in our ArcGIS Online org.

The arcgis api is fantastic and really is the tool I've been waiting for to try and streamline the admin of portal but if it doesn't fit with the security model ESRI have rolled out then its going to cause some headaches for admins since sharing and collaboration are the best things about this platforms.

Has anyone else had problems with interconnected users and groups?

[simoxu]

I don't fully understand the situation without viewing your code. but I would guess that you shared a group (or several groups) with a member of another organisation, and you want to list all the groups that is relevant to that member.

From the security point of view, it seems a security problem if the API allows you to do so. The reason is simple, because this user is a member of another organisation, s/he may be a member of some groups which that organisation does not intend to share with other organisation or the public. This user just happened to be given access to some of your shared groups, but he is not a member of your organization in AGOL, this is very important to stress here. 

For your organization members, to get the groups that you have access, it's very straight-forward:

user = gis.users.get("username")

theList = [g.title for g in user.groups]

You can't view the groups related to a member of another AGOL organisation without being a member of that organisation yourself and being authorized to do so.

I hope it make sense

[MikeKing2]

Hi Simon - its actually the reverse situation.  Some of my organisations members are in groups that belong to other organisations i.e groups that have been shared with our org.  Because they belong to someone elses's AGOL and my org is not admin of that group I (quite rightly) can't read the permissions of the group - however I also can't even read the groups in my org that user is a member of.  Because the users groups property is returned from the API as a list - the whole list is locked out because one group is not authorized to the users home organisation admin.  If you try to execute your code on a user that is a member of another orgs group it will fail as soon as g.title is retrieved.

I'm not sure if its a bug per se but an over simplification of the security model into python objects.  So now the only way I can get a users groups is to list the group memberships and then link that back to the user list.  Which is just a bit frustrating since its just more work around rather than a clean solution.

[simoxu]

I just did a quick test, there was no issue.

I happen to have access to two AGOL organisations, let's say gis1 and gis2.

In gis1 I set up an account simoxu_user, and in gis2 I created a group called "Just a test" and invited simoxu_user to this group. now I am set up to do the test.

In gis1:

# the title of the shared group from gis2 org
test_g_n = 'Just a  test'

simoxu_user = gis1.users.get('simoxu_user')
list1 = [g.title for g in simoxu_user.groups]

# list all the groups that in gis1 org
org_groups = gis1.groups.search()
list2 = [g.title for g in org_groups]

# you can print list1 and list2 to visually check and compare, or use the following code if there lots of groups in the AGOL org.
 
if test_g_n in list2:
    print(f"\'{test_g_n}\' is an internal group in the AGOL Org")
else:
    print(f"\'{test_g_n}\' is an external group in the AGOL org")
    if test_g_n in list1:
        print('It can be listed for the user that the group is being shared with')
    else:
        print("It cannot be listed for the user")‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The result should be:

'Just a  test' is an external group in the AGOL org It can be listed for the user that the group is being shared with

It works for me at least. So I would suggest to contact an ESRI support to have a closer from the backstage if possible.

[MikeKing2]

Thanks Simo - that narrows down a different org is fine.  I think the issue is that (in your example) I (as admin of gis1) have do not have membership of gis2 org or edit permissions (actually not membership either) of gis2's group "Just a test".  I wonder if you remove yourself from "just a test" or from gis2 entirely whether you could still execute that code?

[simoxu]

Hi Mike, I don't have a shared accounts (named user) in two AGOL organisations, I don't feel it's possible since the username has to be unique in AGOL. As a person, I have membership in both orgs, but from the authorization point of view, I have two named users (registered using different email accounts to keep them completely separate) in AGOL, they should not be linked, and they should not authorize each other automatically...

I know it does not explain what your are experiencing, hope ESRI technician can have a look at your problem, and get the mystery solved. Good luck

[MikeKing2]

Thanks for testing Simo.  I think I'll have to see what ESRI has to say.  My situation is I have users in gis 1 that have been invited to work on projects in other organisations (e.g. gis2) using their gis1 account.  It works great and really is a big step forward in collaboration workflows - I've found it really useful.  Its just that I've found that scripting reports on groups and permissions etc its now a bit more complicated.  I see if ESRI has a better way.

[JonathanLebowitz]

A bug has been logged for this issue: BUG-000145104. The workarounds are as follows:

1) An Administrator can view all the groups a member of their organization is in, both internal and external, from the ArcGIS Online user interface, regardless of the "Who can view this group?" setting of the group.

2) Replace user.groups with user.__dict__['groups'] as an alternative means of retrieving a list of Group objects.

Thank you for being a valued Esri customer!