Elimina un rol
Qualsevol rol excepte el de propietari, i només un cop has dit on van els qui el tenen.
Executa la crida real contra el teu espai de treball, amb la teva pròpia clau.
DELETE /roles/{id}
Qualsevol rol excepte el de propietari, i només un cop has dit on van els qui el tenen.
Exemple
Necessita roles:write. reassignTo anomena el rol al qual es mouen tots els membres i totes les claus d'API que tenen aquest.
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \ -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "deleted": true, "reassigned": 3, "keysReassigned": 1}reassignTo viatja com a paràmetre de QUERY i no dins d'un cos. Un cos en un DELETE és legal i àmpliament incompatible (diversos runtimes el descarten, i uns quants proxies també), i un reassignTo descartat és indistingible d'un que no s'ha enviat mai, que és precisament el cas que aquest endpoint rebutja en comptes d'endevinar.
És obligatori des del moment en què algú té el rol: sense ell, role_in_use, un 409, amb param: "reassignTo", que és la solució real. A sota, la columna és ON DELETE RESTRICT, de manera que no hi ha cap camí on eliminar un rol canviï en silenci el que algú pot fer.
Les claus d'API es reapunten en comptes de quedar òrfenes, i aquesta és la meitat subtil. Una clau el rol de la qual desaparegués recauria en un sostre NULL, i un sostre null és MÉS AMPLE que el rol que acaba de marxar, de manera que eliminar un rol restrictiu, altrament, promocionaria en silenci totes les claus que limitava.
Els dos recomptes van separats perquè són dues coses diferents a anar a comprovar: reassigned són persones, que se n'adonaran, i keysReassigned són programes, que no.
El rol de propietari no es pot eliminar (role_undeletable, un 409) perquè anomena el compte al qual està vinculat l'espai de treball i no una feina que faci ningú. Tota la resta de rols pot caure, tant els sembrats Admin, Member, Viewer, Developer i Billing com un que hagi escrit algú: són un punt de partida, i un espai de treball sense integracions no té cap ús per a una fila Developer de la qual no se li permet desfer-se. Comprova deletable abans d'oferir el botó; només el propietari respon false.
Eliminar un rol SEMBRAT no és permanent, així que no redactis el diàleg com si ho fos. GET /roles torna a sembrar qualsevol fila de plantilla que falti, i una eliminació no deixa cap làpida, de manera que la lectura següent de la llista torna a posar Developer amb un id nou. El que fa que deixi de tornar és canviar-li el nom (una fila reanomenada conserva el seu builtin i continua entrant en conflicte amb la sembra), o bé que un altre rol prengui el nom, ja que el sembrador omet una fila el nom de la qual ja està agafat.