Een rol verwijderen
Elke rol behalve de owner-rol, en pas zodra je hebt gezegd waar de houders naartoe gaan.
Voert de echte aanroep uit op je workspace, met je eigen sleutel.
DELETE /roles/{id}
Elke rol behalve de owner-rol, en pas zodra je hebt gezegd waar de houders naartoe gaan.
Voorbeeld
Vereist roles:write. reassignTo noemt de rol waar elk lid en elke API-sleutel op deze rol naartoe gaat.
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 mee als QUERY-parameter en niet in een body. Een body op DELETE is toegestaan en wordt breed niet ondersteund (verschillende runtimes laten hem vallen en een aantal proxy's ook), en een weggevallen reassignTo is niet te onderscheiden van een die nooit is verstuurd, precies het geval waarin dit endpoint weigert in plaats van gokt.
Hij is verplicht zodra iemand de rol heeft: zonder hem volgt role_in_use, een 409, met param: "reassignTo", wat de daadwerkelijke oplossing is. De kolom is er onderliggend ON DELETE RESTRICT, dus er is geen pad waarbij het verwijderen van een rol stilletjes verandert wat iemand kan doen.
API-sleutels worden omgezet in plaats van verweesd achtergelaten, en dat is de subtiele helft. Een sleutel waarvan de rol verdween zou terugvallen op een NULL-plafond, en een null-plafond is RUIMER dan de rol die net verdween, dus het verwijderen van een restrictieve rol zou anders stilletjes elke sleutel promoveren die hij begrensde.
De twee tellingen staan apart omdat het twee verschillende dingen zijn om na te gaan: reassigned zijn mensen, die het merken, en keysReassigned zijn programma's, die dat niet doen.
De owner-rol kan niet worden verwijderd (role_undeletable, een 409) omdat hij het account noemt waarop de workspace is gesleuteld en niet een taak die iemand uitvoert. Elke andere rol kan weg, de geseede Admin, Member, Viewer, Developer en Billing net zo goed als een die iemand zelf heeft geschreven: ze zijn een startpunt, en een workspace zonder integraties heeft niets aan een Developer-rij waar hij niet vanaf mag. Controleer deletable voordat je de knop aanbiedt; alleen de owner-rol antwoordt false.
Het verwijderen van een GESEEDE rol is niet blijvend, dus formuleer het dialoogvenster niet alsof het dat wel is. GET /roles seedt elke ontbrekende sjabloonrij opnieuw, en een verwijdering laat geen grafsteen achter, dus de volgende keer dat de lijst wordt gelezen staat Developer er weer onder een nieuw id. Hernoemen is wat ervoor zorgt dat hij niet terugkomt (een hernoemde rij behoudt zijn builtin en blijft botsen met de seed), of een andere rol die de naam inneemt doet hetzelfde, want de seeder slaat een rij over waarvan de naam al vergeven is.