API

ロールを削除する

オーナー以外のどのロールでも削除できますが、保持者の移動先を指定した場合に限ります。

DELETEapi.openemail.uk/roles/{id}

実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。

DELETE /roles/{id}

オーナー以外のどのロールでも削除できますが、保持者の移動先を指定した場合に限ります。

例

roles:write が必要です。reassignTo には、このロールを持つすべてのメンバーとすべての API キーの移動先ロールを指定します。

curl

curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \  -H "$AUTH"

レスポンス

{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "deleted": true,  "reassigned": 3,  "keysReassigned": 1}

reassignTo はボディではなくクエリパラメータとして渡します。DELETE にボディを付けることは規格上は認められていますが、広くサポートされていません（いくつかのランタイムが破棄し、少なからぬプロキシも破棄します）。破棄された reassignTo は、そもそも送られなかったものと区別が付きません。このエンドポイントは、まさにその場合を推測せずに拒否します。

このロールを誰かが持っている時点で必須になります。指定がないと role_in_use、409 になり、実際の対処方法である param: "reassignTo" を伴います。裏側の列は ON DELETE RESTRICT なので、ロールの削除が誰かにできることを静かに変えてしまう経路はありません。

API キーは孤立させるのではなく付け替えられます。ここが分かりにくい半面です。ロールが消えたキーは NULL の上限にフォールバックしますが、null の上限は今しがた消えたロールより「広い」ので、そうしなければ制限的なロールを削除することで、そのロールが抑えていたすべてのキーを静かに昇格させてしまいます。

2 つのカウントが分かれているのは、確認しに行く先が 2 つの別物だからです。reassigned は人で、本人が気付きます。keysReassigned はプログラムで、こちらは気付きません。

オーナーロールは削除できません（role_undeletable、409）。誰かの職務ではなく、ワークスペースが紐づくアカウントを指すものだからです。それ以外のロールは、誰かが自分で書いたロールと同じように、シードされた Admin、Member、Viewer、Developer、Billing も削除できます。これらは出発点であり、連携を一切作らないワークスペースには、消すことを許されない Developer の行は不要です。ボタンを出す前に deletable を確認してください。false を返すのはオーナーだけです。

シードされたロールの削除は恒久的ではないので、ダイアログの文言をそのように書かないでください。GET /roles は欠けているテンプレート行を再シードし、削除は tombstone を残さないので、次に一覧を読んだときに Developer が新しい id で戻ってきます。戻ってこないようにするには名前を変えるか（名前を変えた行は builtin を保持し、シードと競合し続けます）、別のロールにその名前を取らせます。シーダーは名前がすでに使われている行をスキップするからです。