所以我不相信这些用户会出现在你的AGOL成员的标准搜索,例如users.search(…
但会在合作组的组成员中显示出来。
所以可能是对所有成员的标准搜索,然后对每个组中的成员进行比较。组中的成员(但不在标准用户搜索中)可能是协作成员。
在不比较所有用户列表与组中的用户列表的情况下,您可以查看每个用户对象的dir()长度的差异,或者更显式地尝试访问通常在您的组织的用户对象中公开的属性,该属性可能不存在(您无法看到)在来自合作组织的用户对象中,如user. orgid(在尝试中,除非它会出错)。
谢谢你的回复@DavidPike
我确实观察到,来自合作组织的用户没有“orgId”属性。但是,我不愿意将脚本逻辑建立在它的基础上,除非它以这种方式正式记录。
我正在开发的脚本是报告与大型国家机构的AGOL网站的合作组织共享的项目。合作的组织用户将与QA组共享项目。脚本/笔记本将检查共享项目的元数据,检查完整性评分,如果评分不合格,则向所有者报告。如果满足要求的元数据标准,将项目从“QA”组提升到“PROD”组。我发现要满足这个简单的用户故事需要编写很多脚本,主要原因是缺少API。首先,AGOL不支持webhook,当合作用户共享项目时提供接近实时的反馈。因此,编写一个脚本,以特定的模式(例如组名中的“QA”)扫描组中的所有项目,查找项目是否由来自合作伙伴组织的用户拥有(因此出现了这个线程),然后检查元数据。我还发现,即使脚本作为AGOL管理用户运行,我也无法以编程方式将项目提升到不同的组。
欢呼,
Vish