Ir a la documentación
API

Eliminar un rol

Cualquier rol salvo el de propietario, y solo una vez que hayas indicado adónde van quienes lo tienen.

DELETEapi.openemail.uk/roles/{id}

Ejecuta la llamada real contra tu espacio de trabajo, con tu propia clave.

DELETE /roles/{id}

Cualquier rol salvo el de propietario, y solo una vez que hayas indicado adónde van quienes lo tienen.

Ejemplo

Requiere roles:write. reassignTo nombra el rol al que se trasladan todos los miembros y todas las claves de API que están en este.

curl
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \  -H "$AUTH"
Respuesta
{  "object": "role",  "id": "role_2b81de079c1f0a4b7e05d386",  "deleted": true,  "reassigned": 3,  "keysReassigned": 1}

reassignTo viaja como parámetro de CONSULTA y no en un cuerpo. Un cuerpo en DELETE es legal y está ampliamente sin soportar (varios runtimes lo descartan, y también unos cuantos proxies), y un reassignTo descartado es indistinguible de uno que nunca se envió, que es justamente el caso que este endpoint rechaza en lugar de adivinar.

Es obligatorio en cuanto alguien tiene el rol: sin él, role_in_use, un 409, con param: "reassignTo", que es la solución real. Por debajo, la columna es ON DELETE RESTRICT, así que no hay ningún camino por el que eliminar un rol cambie en silencio lo que alguien puede hacer.

Las claves de API se reapuntan en lugar de quedar huérfanas, y esa es la mitad sutil. Una clave cuyo rol desapareciera caería en un techo NULL, y un techo nulo es MÁS AMPLIO que el rol que acaba de irse, así que eliminar un rol restrictivo ascendería en silencio todas las claves que limitaba.

Los dos recuentos están separados porque son dos cosas distintas que hay que ir a revisar: reassigned son personas, que se darán cuenta, y keysReassigned son programas, que no.

El rol de propietario no se puede eliminar (role_undeletable, un 409) porque nombra la cuenta sobre la que está indexado el espacio de trabajo y no un trabajo que haga alguien. Todos los demás roles pueden desaparecer, tanto los precargados Admin, Member, Viewer, Developer y Billing como uno que haya escrito alguien: son un punto de partida, y un espacio de trabajo sin integraciones no tiene ningún uso para una fila Developer de la que no se le permite deshacerse. Comprueba deletable antes de ofrecer el botón; solo el propietario responde false.

Eliminar un rol PRECARGADO no es permanente, así que no redactes el diálogo como si lo fuera. GET /roles vuelve a precargar la fila de plantilla que falte, y una eliminación no deja lápida, así que la siguiente lectura de la lista devuelve Developer con un id nuevo. Renombrarlo es lo que hace que deje de volver (una fila renombrada conserva su builtin y sigue entrando en conflicto con la precarga), o bien que otro rol tome el nombre, ya que el seeder omite una fila cuyo nombre ya está ocupado.