Supprimer un rôle
N'importe quel rôle sauf `owner`, et seulement une fois que vous avez dit où vont ses détenteurs.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
DELETE /roles/{id}
N'importe quel rôle sauf owner, et seulement une fois que vous avez dit où vont ses détenteurs.
Exemple
Nécessite roles:write. reassignTo nomme le rôle vers lequel se déplacent tous les membres et toutes les clés API rattachés à celui-ci.
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \ -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "deleted": true, "reassigned": 3, "keysReassigned": 1}reassignTo voyage comme paramètre de QUERY plutôt que dans un corps. Un corps sur DELETE est légal et largement non pris en charge (plusieurs environnements d'exécution le suppriment, ainsi qu'un certain nombre de proxys), et un reassignTo supprimé est indiscernable d'un reassignTo qui n'a jamais été envoyé, ce qui est précisément le cas que ce point de terminaison refuse au lieu de le deviner.
Il devient obligatoire dès que quelqu'un détient le rôle : sans lui, role_in_use, un 409, portant param: "reassignTo", qui est la véritable correction. En dessous, la colonne est en ON DELETE RESTRICT : il n'existe donc aucun chemin par lequel la suppression d'un rôle modifie discrètement ce que quelqu'un peut faire.
Les clés API sont repointées plutôt que laissées orphelines, et c'est là la moitié subtile. Une clé dont le rôle aurait disparu retomberait sur un plafond NULL, et un plafond null est PLUS LARGE que le rôle qui vient de disparaître : supprimer un rôle restrictif promouvrait donc sinon discrètement chaque clé qu'il plafonnait.
Les deux compteurs sont distincts parce que ce sont deux choses différentes à aller vérifier : reassigned désigne des personnes, qui le remarqueront, et keysReassigned des programmes, qui ne le remarqueront pas.
Le rôle owner ne peut pas être supprimé (role_undeletable, un 409) parce qu'il nomme le compte sur lequel l'espace de travail est indexé plutôt qu'un métier que quelqu'un exerce. Tous les autres rôles peuvent disparaître, les rôles amorcés Admin, Member, Viewer, Developer et Billing autant qu'un rôle écrit par quelqu'un : ce sont un point de départ, et un espace de travail sans intégrations n'a que faire d'une ligne Developer dont il n'a pas le droit de se débarrasser. Vérifiez deletable avant de proposer le bouton ; seul owner répond false.
La suppression d'un rôle AMORCÉ n'est pas définitive : ne formulez donc pas la boîte de dialogue comme si elle l'était. GET /roles réamorce toute ligne modèle manquante, et une suppression ne laisse aucune pierre tombale : la prochaine lecture de la liste remet donc Developer en place sous un nouvel id. C'est le fait de le renommer qui l'empêche de revenir (une ligne renommée conserve son builtin et continue d'entrer en conflit avec l'amorce), ou bien qu'un autre rôle prenne le nom, puisque l'amorceur saute une ligne dont le nom est déjà pris.