ロール

const roles = await openemail.roles.list()const role = await openemail.roles.get('role_…') const support = await openemail.roles.create({  name: 'Support',  description: 'Answers the shared inboxes and nothing else.',  permissions: ['emails:send', 'threads:write', 'labels:write'],}) console.log(support.permissions) await openemail.roles.update(support.id, {  permissions: [...support.permissions, 'templates:read'],}) await openemail.roles.delete(support.id, { reassignTo: 'role_…' }) const vocabulary = await openemail.roles.listPermissions()

support.permissions の要素は 3 つではなく 6 つになる。emails:send は emails:read を、threads:write は threads:read を、labels:write は labels:read を連れてくるからである。中身を推測せず、リストを読み直すこと。

ロールが定めるのは、その人が何をしてよいかである。どのアドレスに対してそれをしてよいかはもう一方の軸であり、openemail.members に属する。そちらの grantAddress と revokeAddress を参照。「メールを送信してよい」と「invoices@ として送信してよい」は別の文であり、サポート担当者をもう 1 人雇ったワークスペースは、前者に触れずに後者だけを変更する。

分岐には builtin の名前ではなく editable と deletable を使うこと。両方が false になるのはオーナーだけであり、その権限リストは「来年生まれるものも含めたすべての権限」であって、保存されているのではなく計算される。それ以外のロールは、ワークスペースに最初から用意される 5 つを含めて、どちらにも true を返す。誰かが名前を変更したロールでも両方の値は正しいままであり、一方で名前はもう何も語らなくなっている。

ロールに紐付けて発行されたキーができることは、そのキー自身のスコープとロールの権限の積集合であり、リクエストごとに境界で解決される。したがってロールを狭めれば、キーをローテーションしなくても、そのキーの権限はその場で取り消される。逆にロールを持たないキーには上限がまったくないため、ロールが null であることはキーにとって最も狭い状態ではなく、最も広い状態である。

roles.delete がキーの移動先を必須としているのもそのためである。キーを孤立させれば上限が丸ごと外れ、そのロールが抑えていたすべての資格情報が黙って昇格してしまう。