Przejdź do dokumentacji
API

Wypisz uprawnienia

Całe słownictwo, wraz ze zdaniem i nagłówkiem, pod którym renderuje się każda pozycja.

GETapi.openemail.uk/roles/permissions

Uruchamia prawdziwe wywołanie na twojej przestrzeni roboczej, twoim własnym kluczem.

GET /roles/permissions

Całe słownictwo, wraz ze zdaniem i nagłówkiem, pod którym renderuje się każda pozycja.

Przykład

Wymaga roles:read. Stała, ta sama odpowiedź dla każdej przestrzeni roboczej, i lista, z której buduje się macierz, zamiast przepisywać ją do własnego kodu.

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

Zarejestrowane PRZED /roles/{id}, inaczej permissions jest czytane jako identyfikator roli i każde żądanie do niego kończy się 404. /rules/runs ma nad sobą tę samą notatkę, a /tracking/stats jeszcze wyżej — obie spisane po tym samym błędzie. Pytanie o rolę naprawdę nazwaną „permissions” pyta więc o rolę i dostaje 404, co jest uczciwą odpowiedzią na to, co wpisano.

scope mówi, czy KLUCZ API może w ogóle mieć dane uprawnienie. Pięć nie może (api-keys:read, api-keys:write, billing:read, billing:write i workspace:manage), bo dla żadnego z nich nie ma endpointu, a klucz nie jest osobą. Ta flaga pozwala jednemu komponentowi renderować i macierz ról, i listę checkboxów przy tworzeniu klucza, zamiast utrzymywać ręcznie drugą kopię tego, co jest czym.

Serwowane, a nie przepisane, z tego samego powodu co lista pól reguł: macierz zbudowana ze skopiowanej tablicy nadal oferuje uprawnienie w dniu, w którym zmieni ono nazwę, i nigdy nie zaoferuje dodanego w zeszłym tygodniu. group to nagłówek, pod którym się renderuje, i w razie czego przyjmuje other, zamiast wyjść jako undefined. Uprawnienie, którego nikt nie widzi, to uprawnienie, którego nikt nie audytuje.

Kolejność jest kanoniczna: to kolejność, w jakiej wraca tablica permissions zapisanej roli, więc klient renderujący tę listę i klient renderujący rolę pokazują te same uprawnienia w tej samej kolejności.

Brak koperty poza object i data. Słownictwo jest zamknięte i krótkie, więc nie ma kursora ani hasMore, inaczej niż na każdej innej liście w tym API.