Zur Dokumentation springen
API

Berechtigungen auflisten

Das gesamte Vokabular, mit dem Satz und der Überschrift, unter der jeder Eintrag gerendert wird.

GETapi.openemail.uk/roles/permissions

Führt den echten Aufruf gegen Ihren Workspace aus, mit Ihrem eigenen Schlüssel.

GET /roles/permissions

Das gesamte Vokabular, mit dem Satz und der Überschrift, unter der jeder Eintrag gerendert wird.

Beispiel

Benötigt roles:read. Eine Konstante, dieselbe Antwort für jeden Workspace, und die Liste, aus der eine Matrix gebaut wird, statt sie in den eigenen Code abzuschreiben.

curl
curl "$OE/roles/permissions" -H "$AUTH"
Antwort
{  "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    }  ]}

Registriert VOR /roles/{id}, sonst wird permissions als Rollen-ID gelesen und jede Anfrage darauf endet in einem 404. /rules/runs trägt denselben Hinweis darüber und /tracking/stats ebenso, beide nach demselben Bug geschrieben. Wer eine Rolle abfragt, die tatsächlich „permissions“ heißt, fragt damit nach einer Rolle und bekommt einen 404, was die ehrliche Antwort auf das Getippte ist.

scope sagt, ob ein API-KEY die Berechtigung überhaupt halten darf. Fünf dürfen es nicht (api-keys:read, api-keys:write, billing:read, billing:write und workspace:manage), weil es für keine davon einen Endpunkt gibt und ein Key keine Person ist. Dieses Flag ist es, was eine einzige Komponente sowohl die Rollenmatrix als auch die Checkbox-Liste bei der Key-Erstellung rendern lässt, statt einer zweiten, von Hand gepflegten Kopie davon, was wozu gehört.

Ausgeliefert statt abgeschrieben, aus dem Grund, den die Feldliste der Regeln nennt: Eine Matrix, die aus einem kopierten Array gebaut ist, bietet an dem Tag, an dem eine Berechtigung umbenannt wird, weiterhin die alte an und bietet die von letzter Woche nie an. group ist die Überschrift, unter der ein Eintrag gerendert wird, und fällt auf other zurück, statt als undefined rauszugehen. Eine Berechtigung, die niemand sieht, ist eine Berechtigung, die niemand prüft.

Die Reihenfolge ist kanonisch: Es ist die Reihenfolge, in der das permissions-Array einer gespeicherten Rolle zurückkommt; ein Client, der diese Liste rendert, und einer, der eine Rolle rendert, zeigen dieselben Berechtigungen also in derselben Abfolge.

Kein Umschlag über object und data hinaus. Das Vokabular ist geschlossen und kurz, es gibt also keinen Cursor und kein hasMore, anders als bei jeder anderen Liste in der API.