パーミッションを一覧する
語彙全体を、各エントリの説明文と、それが表示される見出しとともに返します。
実際の呼び出しを、ご自身のキーで自分のワークスペースに対して実行します。
GET /roles/permissions
語彙全体を、各エントリの説明文と、それが表示される見出しとともに返します。
例
roles:read が必要です。定数で、どのワークスペースでも同じ応答になります。自分のコードに書き写すのではなく、ここから権限マトリクスを組み立ててください。
curl "$OE/roles/permissions" -H "$AUTH"{ "object": "list", "data": [ { "object": "permission", "id": "emails:send", "label": "Send email", "group": "mail", "scope": true }, { "object": "permission", "id": "members:write", "label": "Add and remove people, and change what they can reach", "group": "people", "scope": true }, { "object": "permission", "id": "api-keys:write", "label": "Create and revoke API keys", "group": "developer", "scope": false }, { "object": "permission", "id": "workspace:manage", "label": "Rename the workspace, remove domains and delete it", "group": "workspace", "scope": false } ]}/roles/{id} より「前に」登録する必要があります。さもないと permissions がロール id として読まれ、このエンドポイントへのリクエストはすべて 404 になります。/rules/runs にも同じ注意書きが付いており、その上の /tracking/stats にも付いています。どちらも同じバグの後に書かれました。したがって、本当に「permissions」という名前のロールを要求すると、ロールを要求したことになり 404 が返ります。それが入力に対する正直な応答です。
scope は、そのパーミッションを API キーが保持できるかどうかを示します。5 つは保持できません（api-keys:read、api-keys:write、billing:read、billing:write、workspace:manage）。いずれにもエンドポイントがなく、キーは人ではないからです。このフラグのおかげで、ロールのマトリクスとキー作成時のチェックボックス一覧を 1 つのコンポーネントで描画でき、どちらがどちらかを手で管理する 2 つ目の写しを持たずに済みます。
書き写すのではなく配信しているのは、ルールのフィールド一覧と同じ理由です。コピーした配列から組み立てたマトリクスは、パーミッションの名前が変わった日にも古い名前を出し続け、先週追加されたものを決して出しません。group はそれが表示される見出しで、undefined のまま出ていくのではなく other にフォールバックします。誰にも見えないパーミッションは、誰も監査しないパーミッションです。
順序は正規です。保存されたロールの permissions 配列が返ってくる順序と同じなので、この一覧を描画するクライアントとロールを描画するクライアントは、同じパーミッションを同じ順序で表示します。
object と data 以外のエンベロープはありません。語彙は閉じていて短いので、API の他のすべての一覧と違い、カーソルも hasMore もありません。