見つめている：
https://developers.google.com/drive/v2/reference/permissions#resource
ACLの電子メールアドレス値を含むvalues属性は、APIによって返されません。値が返されない理由は明確ではありません。プライバシーの問題だと思いますが、Drive SDKは、古いDocuments List API v3で可能なドキュメントの移行（あるGoogleアカウントから別のアカウントへの）のユースケースをサポートできないことを意味します。
今のところ、プロジェクトにDriveAPIとDocsv3 APIの両方のスコープを追加し、Docs API呼び出しを使用してACLを取得することを検討していますが、理想的にはDriveAPI呼び出しのみを使用できます。私は何かが足りないのですか？ACL電子メールアドレスの取得を可能にする特別なスコープをDriveAPIに追加できますか、それともこれを処理する他の方法がありますか？
ジェイ
ジェイに質問してくれてありがとう、そしてアリ・アフシャールに答えてくれてありがとう！
残念ながら、ユーザーのメールアドレスがなくても次のシナリオが機能するとGoogleがどのように考えているのかわかりません。
Documents List API v3では、ファイルAをファイルBにコピーし、ファイルAのACL情報（ユーザーの電子メールアドレスを含む）を取得して、ファイルBにACLとして追加することができます。
ドライブAPIを使用すると、ほぼ同じアクセス許可情報を取得できますが、ユーザーの電子メールアドレスは必要ありません。これは、ファイルBを同じユーザーに再共有するために必要です。
補足として：GAS DefaultService DocsListを使用する場合でも、getEditors（）またはgetViewers（）を使用してeditor/viewersを受け取ることができます。ファイルを手動で共有すると、すべてのメールアドレスも表示されます。
ですから、私に言わせれば、プライバシーの問題は貴重な議論ですが、ここでは当てはまりません。
1月
あなたは絶対に正しいです、電子メールアドレスはプライバシーのために隠されています。ユーザーがファイルにアクセスできる他のすべてのユーザーの電子メールアドレスを表示する必要があるのは正しくありません。しかし、私は私が完全に問題を抱えているかどうかはわかりません。サービスアカウントを使用して移行していますか、それともユーザーが個別に移行を承認していますか？
権限フィードの値はユーザーごとに一貫しており、その値はユーザーのaboutフィードで利用できます。ユーザーのメールアドレスを知っていると思いますので、サービスアカウントを使用して各ユーザーを承認し、データを移行できます。
DriveAPIスコープとDocsv3APIスコープはほとんど同じスコープである必要はありません。
また、この古いスレッドを復活させたところ、ドキュメントの移行中に同じ問題が発生しました。
A workaround:
- Create a temporary folder
- Insert a permission for the user
- retrieve the id from the permission
良くありませんが、私にとってはうまくいきます。
この質問が投稿されてから、Drive APIが更新され、 permissions.insert（）（属性）permissionIdで送信できるようになりました。これにより、電子メールアドレスを知らなくてもACLを移行できます（permissionIdsを新しいファイルに直接コピーするだけです）。id
さらに：
permitmissions.getIdForEmail（） API呼び出しは、特定の電子メールアドレスのIDを取得する簡単な方法を提供します
パーミッション.get（）またはpermissions.insert（）を使用してファイルのパーミッションを返すdomain場合、ACLがセキュリティ上の懸念を引き起こすかどうかを判断するのに役立つ属性が含まれます。
これらの機能は、実際のACL電子メールアドレスの取得が必要なほとんどのユースケースをカバーしていると思います。