看着：
https://developers.google.com/drive/v2/reference/permissions#resource
API不返回包含ACL的电子邮件地址值的values属性。目前尚不清楚为什么没有返回该值，我认为这是一个隐私问题，但这意味着Drive SDK无法支持文档迁移（从一个Google帐户到另一个）旧旧Documents List API v3可以使用的用例：
目前我正在为我的项目添加Drive API和Docs v3 API范围，只是使用Docs API调用来检索ACL，但理想情况下我只能使用Drive API调用。我错过了什么吗？是否可以将特殊范围添加到允许ACL电子邮件地址检索的Drive API中，还是有其他方法来处理此问题？
杰
答案 0 :(得分：2)
感谢Jay的问题，感谢你的回答Ali Afshar！
不幸的是，我不明白Google如何认为以下方案在没有用户的电子邮件地址的情况下仍然有效：
在Documents List API v3中，您可以将文件A复制到文件B，检索文件A的ACL信息（包括用户的电子邮件地址），然后将它们作为ACL添加到文件B中。
使用Drive API，您可以检索几乎相同的权限信息，但没有用户电子邮件地址，这仍然是将文件B重新共享给同一用户所必需的。
作为旁注：如果您使用GAS DefaultService DocsList，您仍然可以使用getEditors（）或getViewers（）接收编辑器/查看器。如果手动共享文件，您也可以看到所有电子邮件地址。
所以如果你问我，隐私问题是一个有价值的论点，但它确实不适用于此。
扬
答案 1 :(得分：1)
您完全正确，电子邮件地址隐藏起来以保护隐私。用户应该看到有权访问该文件的所有其他用户的电子邮件地址是不对的。但我不确定我是否完全解决了这个问题。您是使用服务帐户进行迁移，还是单独授权迁移的用户？
权限Feed中的值对于每个用户都是一致的，并且该值在用户的about feed中可用。我假设您知道用户的电子邮件地址，因此您可以使用服务帐户为每个用户进行授权，并且可以迁移数据。
您不应该使用Drive API范围和Docs v3 API范围，它们的范围几乎相同。
答案 2 :(得分：1)
同样恢复这个旧线程，我在迁移文档时遇到了同样的问题。
A workaround:
- Create a temporary folder
- Insert a permission for the user
- retrieve the id from the permission
不好，但适合我。
答案 3 :(得分：1)
自此问题发布以来，Drive API已更新，允许permissionId id（domain属性）发送{{1}}。这允许迁移ACL而无需知道电子邮件地址（只需将permissionIds直接复制到新文件中）。
此外：
permissions.insert() API调用提供了获取给定电子邮件地址ID的快捷方式
返回permissions.getIdForEmail()文件的权限时，会包含{{1}}属性，这有助于确定ACL是否引发安全问题。
我相信这些功能涵盖了需要检索实际ACL电子邮件地址的大多数用例。