역할 수정
모든 필드가 선택 사항이며, `permissions`는 목록 전체를 교체합니다.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
PATCH /roles/{id}
모든 필드가 선택 사항이며, permissions는 목록 전체를 교체합니다.
예제
roles:write가 필요합니다. 필드를 생략하면 그대로 두며, 그것이 PATCH의 의미입니다.
curl -X PATCH "$OE/roles/role_2b81de079c1f0a4b7e05d386" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"] }'{ "object": "role", "id": "role_2b81de079c1f0a4b7e05d386", "name": "Support", "description": "Answers the shared inboxes and nothing else.", "permissions": ["emails:read", "threads:read", "labels:read", "contacts:read"], "builtin": null, "editable": true, "deletable": true, "members": 3, "apiKeys": 1, "createdAt": "2026-08-30T10:41:02.000Z", "updatedAt": "2026-08-30T13:02:19.000Z"}permissions는 목록 전체를 교체합니다. 하나만 부여하는 호출은 없고 앞으로도 없을 것입니다. 감사 대상은 목록이고, 인덱스로 지정하는 패치는 탭이 두 개 열린 순간 갱신 손실이 됩니다. 역할을 읽고, 원하는 항목을 바꾸고, 전부 다시 보내십시오. 권한 하나를 보내는 것은 권한을 추가하는 것이 아닙니다. 그 역할은 정확히 그 하나와, 그것이 함의하는 것만 갖게 됩니다.
description은 선택 사항인 동시에 nullable이며, 그 차이가 패치의 핵심입니다. 생략하면 저장된 문장이 유지되고, null을 보내면 지워집니다. nullable이 없으면 공백으로 바꾸는 것 말고는 설명을 없앨 방법이 없습니다.
PATCH가 거부하는 유일한 역할은 owner이며, 그 모든 필드를 거부합니다. role_immutable, param: "roleId"를 담은 409입니다. 시드된 역할을 포함해 나머지는 새 이름이든 새 권한 목록이든 똑같이 받아들입니다. builtin은 역할이 어디서 왔는지를 기록할 뿐, 무엇을 할 수 있는지를 기록하지 않습니다. 다른 역할이 이미 쓰고 있는 이름이면 대신 role_name_taken, param: "name"을 담은 409입니다.
수정은 그 역할을 가진 누구든, API 키를 포함해, 다음 요청에 적용됩니다. 상한이 캐시되지 않고 요청마다 해석되기 때문입니다. 따라서 역할을 좁히는 것은 그 아래 키를 교체하지 않고도 효력이 생기는 실시간 회수입니다. 넓히는 것도 마찬가지로 실시간인데, 그 절반을 기억해 둘 만합니다.