Usuń rolę
Każda rola poza właścicielem i dopiero wtedy, gdy powiesz, dokąd trafiają jej posiadacze.
Uruchamia prawdziwe wywołanie na twojej przestrzeni roboczej, twoim własnym kluczem.
DELETE /roles/{id}
Każda rola poza właścicielem i dopiero wtedy, gdy powiesz, dokąd trafiają jej posiadacze.
Przykład
Wymaga roles:write. reassignTo nazywa rolę, na którą przechodzi każdy członek i każdy klucz API z tej roli.
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \ -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "deleted": true, "reassigned": 3, "keysReassigned": 1}reassignTo podróżuje jako parametr ZAPYTANIA, a nie w ciele żądania. Ciało w DELETE jest legalne i powszechnie nieobsługiwane (kilka środowisk uruchomieniowych je odrzuca, podobnie jak część proxy), a odrzucone reassignTo jest nie do odróżnienia od takiego, którego nigdy nie wysłano — a to właśnie jest przypadek, który ten endpoint odrzuca, zamiast go zgadywać.
Jest wymagane w chwili, gdy ktokolwiek ma tę rolę: bez niego role_in_use, 409, niosące param: "reassignTo", co jest faktyczną poprawką. Pod spodem kolumna jest ON DELETE RESTRICT, więc nie ma ścieżki, na której usunięcie roli po cichu zmienia to, co ktoś może zrobić.
Klucze API są przekierowywane, a nie osierocane, i to jest subtelniejsza połowa. Klucz, którego rola zniknęła, wróciłby do pułapu NULL, a pułap null jest SZERSZY niż rola, która właśnie odeszła, więc usunięcie restrykcyjnej roli po cichu awansowałoby każdy klucz, który ona ograniczała.
Te dwie liczby są osobne, bo to dwie różne rzeczy do sprawdzenia: reassigned to ludzie, którzy zauważą, a keysReassigned to programy, które nie zauważą.
Roli właściciela nie da się usunąć (role_undeletable, 409), ponieważ nazywa konto, na które zarejestrowana jest przestrzeń robocza, a nie zadanie, które ktoś wykonuje. Każda inna rola może odejść — zaseedowane Admin, Member, Viewer, Developer i Billing tak samo jak ta, którą ktoś napisał: są punktem wyjścia, a przestrzeń robocza bez integracji nie ma pożytku z wiersza Developer, którego nie wolno jej się pozbyć. Sprawdź deletable, zanim pokażesz przycisk; tylko właściciel odpowiada false.
Usunięcie roli ZASEEDOWANEJ nie jest trwałe, więc nie formułuj okna dialogowego tak, jakby było. GET /roles ponownie zaseeduje każdy brakujący wiersz szablonowy, a usunięcie nie zostawia nagrobka, więc następny odczyt listy wstawia Developer z powrotem pod nowym id. Dopiero zmiana nazwy sprawia, że przestaje wracać (przemianowany wiersz zachowuje swój builtin i nadal koliduje z seedem), albo zrobi to inna rola zajmująca tę nazwę, ponieważ seeder pomija wiersz, którego nazwa jest zajęta.