역할 삭제
소유자를 제외한 모든 역할. 단, 보유자들이 어디로 갈지 지정한 뒤에만 가능합니다.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
DELETE /roles/{id}
소유자를 제외한 모든 역할. 단, 보유자들이 어디로 갈지 지정한 뒤에만 가능합니다.
예제
roles:write가 필요합니다. reassignTo는 이 역할에 있던 모든 멤버와 모든 API 키가 옮겨 갈 역할을 지정합니다.
curl -X DELETE "$OE/roles/role_2b81de079c1f0a4b7e05d386?reassignTo=role_c40a95f21cc65d31c2a89e07" \ -H "$AUTH"{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "deleted": true, "reassigned": 3, "keysReassigned": 1}reassignTo는 본문이 아니라 쿼리 파라미터로 전달됩니다. DELETE의 본문은 합법이지만 널리 지원되지 않으며(여러 런타임과 다수의 프록시가 버립니다), 버려진 reassignTo는 애초에 보내지 않은 것과 구분할 수 없습니다. 이 엔드포인트는 바로 그 경우를 추측하지 않고 거부합니다.
역할을 가진 사람이 하나라도 있으면 필수가 됩니다. 없으면 role_in_use, 409이며 실제 해결책인 param: "reassignTo"를 담습니다. 내부적으로 컬럼이 ON DELETE RESTRICT이므로, 역할을 삭제해서 누군가 할 수 있는 일이 조용히 바뀌는 경로는 없습니다.
API 키는 고아가 되지 않고 다시 지정되며, 이것이 미묘한 나머지 절반입니다. 역할이 사라진 키는 NULL 상한으로 떨어지는데, null 상한은 방금 사라진 역할보다 넓습니다. 그러면 제한적인 역할을 삭제하는 것이 그 역할이 제한하던 모든 키를 조용히 승격시키게 됩니다.
두 개수가 분리된 이유는 확인하러 가야 할 대상이 서로 다르기 때문입니다. reassigned는 사람이고 그들은 알아차리며, keysReassigned는 프로그램이고 알아차리지 못합니다.
owner 역할은 삭제할 수 없습니다(role_undeletable, 409). 누군가 맡는 일이 아니라 워크스페이스가 귀속된 계정을 가리키기 때문입니다. 다른 역할은 모두 삭제할 수 있습니다. 시드된 Admin, Member, Viewer, Developer, Billing도 누군가 직접 만든 역할과 다르지 않습니다. 이들은 출발점이며, 연동이 하나도 없는 워크스페이스가 없앨 수 없는 Developer 행을 떠안을 이유는 없습니다. 버튼을 노출하기 전에 deletable을 확인하십시오. false로 답하는 것은 owner뿐입니다.
시드된 역할의 삭제는 영구적이지 않으므로, 대화상자를 영구적인 것처럼 쓰지 마십시오. GET /roles는 빠져 있는 템플릿 행을 다시 시드하고, 삭제는 비석을 남기지 않으므로 다음 목록 읽기에서 Developer가 새 id로 되돌아옵니다. 다시 돌아오지 않게 하려면 이름을 바꾸거나(이름이 바뀐 행도 builtin을 유지해 시드와 계속 충돌합니다), 다른 역할이 그 이름을 차지하면 됩니다. 시더는 이름이 이미 쓰인 행을 건너뛰기 때문입니다.