以下是 Team Drive UI 中提供的权限、相应getAccess()
值以及您可以调用的包含该人的文件夹 API 方法之间的映射摘要:
+-----------------------+-------------+-------------------+
| Team Drive Permission | getAccess() | Folder API Method |
+-----------------------+-------------+-------------------+
| Manager | ORGANIZER | (None) |
| Content Manager | NONE | (None) |
| Contributor | EDIT | getEditors() |
| Commenter | COMMENT | getViewers() |
| Viewer | VIEW | getViewers() |
| (None) | NONE | (None) |
+-----------------------+-------------+-------------------+
一些结果:
- 无法知道谁是 Team Drive 上的 Content Manager :请注意Content Manager和不在 Team Drive 上的人是如何返回
NONE
的。因此,即使您知道此人的电子邮件地址,也无法使用该方法知道谁是 Team Drive 上的内容管理员。这可能是 API 中的错误?getAccess()
- 您可以轻松获取所有 Contributors:只需调用该
getEditors()
方法。
getAccess()
您可以获取所有评论者和查看者,但也需要使用:由于评论者和查看者都是通过返回的getViewers
,因此您需要将其与 getAccess() 中返回的结果交叉引用以找到实际的评论者或查看者。
- 没有获取 Manager 或 Content Manager的 API 方法:返回文件夹上一组用户的标准 API 方法都不会返回 Manager 或 Content Manager 组中的任何人。因此,您需要知道经理的电子邮件地址,并且只能使用 getAccess() 来验证他们确实是经理。
getOwner()
总是返回null
。这大概是因为团队云端硬盘上没有单一所有者。null
即使您正好有 1 个经理和 0 个内容经理,它也会返回。
因此,似乎没有办法使用标准 API在团队驱动器(大概分别是Managers和Content ManagersOWNER
)上找到s 或s。相反,您必须已经知道与用户关联的电子邮件地址是什么,然后调用. 这是不幸的。ORGANIZER
getAccess()
我期待以下解决方法起作用:
- 在团队云端硬盘中创建一个虚拟文件。由于Team Drive 中的文件权限完全映射到Edit、Comment、View,因此该
getEditors()
方法现在应该公开 Manager 和 Content Manager。由于它们对文件具有编辑权限,因此它们应该由getEditors()
方法返回。
不幸的是,这也不起作用。结果与文件夹案例完全相同。Manager 和 Content Manager 被隐藏(即 3 个方法都没有返回它们)。内容管理器的 getAccess() 仍然是 NONE,等等。
那么,要获取 Managers 和 Content Managers 的列表,我相信唯一的选择是使用高级 API。特别是,看起来PermissionsteamDrivePermissionDetails[].role
对象恰好返回了映射到 Team Drive 权限的 5 个状态: