Eine Rolle löschen
Jede Rolle außer owner, und erst, wenn Sie gesagt haben, wohin ihre Inhaber wechseln.
Führt den echten Aufruf gegen Ihren Workspace aus, mit Ihrem eigenen Schlüssel.
DELETE /roles/{id}
Jede Rolle außer owner, und erst, wenn Sie gesagt haben, wohin ihre Inhaber wechseln.
Beispiel
Benötigt roles:write. reassignTo benennt die Rolle, auf die jedes Mitglied und jeder API-Schlüssel dieser Rolle wechselt.
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \ -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "deleted": true, "reassigned": 3, "keysReassigned": 1}reassignTo reist als QUERY-Parameter statt im Body. Ein Body bei DELETE ist zulässig und wird weithin nicht unterstützt (mehrere Laufzeiten verwerfen ihn, ebenso etliche Proxys), und ein verworfenes reassignTo ist nicht von einem zu unterscheiden, das nie gesendet wurde – genau der Fall, den dieser Endpunkt ablehnt, statt zu raten.
Es ist in dem Moment erforderlich, in dem irgendjemand die Rolle hält: ohne es role_in_use, ein 409, mit param: "reassignTo", was die eigentliche Lösung ist. Die Spalte ist darunter ON DELETE RESTRICT, es gibt also keinen Weg, auf dem das Löschen einer Rolle stillschweigend ändert, was jemand tun kann.
API-Schlüssel werden umgehängt statt verwaist, und das ist die subtile Hälfte. Ein Schlüssel, dessen Rolle verschwunden ist, fiele auf eine NULL-Obergrenze zurück, und eine null-Obergrenze ist WEITER als die gerade entfernte Rolle, sodass das Löschen einer restriktiven Rolle sonst stillschweigend jeden von ihr begrenzten Schlüssel beförderte.
Die beiden Zahlen sind getrennt, weil es zwei verschiedene Dinge sind, die man prüfen gehen muss: reassigned sind Menschen, die es merken werden, und keysReassigned sind Programme, die es nicht merken.
Die owner-Rolle kann nicht gelöscht werden (role_undeletable, ein 409), weil sie das Konto benennt, auf das der Workspace geschlüsselt ist, und keine Aufgabe, die irgendjemand ausübt. Jede andere Rolle kann gehen, die vorinstallierten Admin, Member, Viewer, Developer und Billing genauso wie eine selbst geschriebene: Sie sind ein Ausgangspunkt, und ein Workspace ohne Integrationen hat keine Verwendung für eine Developer-Zeile, die er nicht loswerden darf. Prüfen Sie deletable, bevor Sie den Button anbieten; nur owner antwortet false.
Das Löschen einer VORINSTALLIERTEN Rolle ist nicht endgültig, formulieren Sie den Dialog also nicht so, als wäre es das. GET /roles sät jede fehlende Vorlagenzeile neu aus, und ein Löschvorgang hinterlässt keinen Grabstein, sodass der nächste Listenaufruf Developer unter einer neuen id zurückbringt. Erst das Umbenennen sorgt dafür, dass sie nicht wiederkommt (eine umbenannte Zeile behält ihr builtin und kollidiert weiterhin mit dem Seed), oder eine andere Rolle, die den Namen übernimmt, denn der Seeder überspringt eine Zeile, deren Name vergeben ist.