ロール

page = client.roles.listputs page.items.size role = client.roles.get("role_8b1f4c2e9a7d3b60e5f1a2c4")puts role[:name] support = client.roles.create(  name: "Support",  description: "Answers the shared inboxes and nothing else.",  permissions: ["emails:send", "threads:write", "labels:write"]) p support[:permissions] client.roles.update(support[:id], permissions: [*support[:permissions], "templates:read"]) client.roles.delete(support[:id], reassign_to: role[:id]) vocabulary = client.roles.list_permissionsp vocabulary.map { |permission| permission[:id] }

support[:permissions] の要素は 3 つではなく 6 つです：emails:send は emails:read を、threads:write は threads:read を、labels:write は labels:read を連れてくるからです。中身を推測せず、リストを読み直してください。

list は OpenEmail::Page を 1 つ返し、list_all はすべてのロールを 1 つの Array で返し、iterate は各ロールをブロックに yield するか、ブロックがなければ Enumerator を返します。ロールは Symbol キーの Hash として返るため、role[:permissions] でリストを読めます。create と update はボディのフィールドをキーワード引数または 1 つの Hash として受け取り、delete は reassign_to: を受け取ります。これは snake_case のキーワード引数で、gem が API 向けに名前を変換します。

ロールが定めるのは、その人が何を「してよいか」です。どの「アドレス」に対してそれをしてよいかはもう一方の軸であり、client.members に属します：メンバーのページの grant_address と revoke_address を参照してください。「メールを送信してよい」と「invoices@ として送信してよい」は別の文であり、サポート担当者をもう 1 人雇ったワークスペースは、前者に触れずに後者だけを変更します。両方に答える権限が 1 つあります：addresses:all を持つロールは、付与なしで、後から追加されたものも含めてすべてのアドレスに届きます。これをロールに付けられるのはアプリ上の人だけです。

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

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

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