역할

const roles = await openemail.roles.list()const role = await openemail.roles.get('role_…') const support = await openemail.roles.create({  name: 'Support',  description: 'Answers the shared inboxes and nothing else.',  permissions: ['emails:send', 'threads:write', 'labels:write'],}) console.log(support.permissions) await openemail.roles.update(support.id, {  permissions: [...support.permissions, 'templates:read'],}) await openemail.roles.delete(support.id, { reassignTo: 'role_…' }) const vocabulary = await openemail.roles.listPermissions()

support.permissions에는 세 개가 아니라 여섯 개가 들어 있습니다. emails:send는 emails:read를, threads:write는 threads:read를, labels:write는 labels:read를 함께 가져옵니다. 짐작하지 말고 목록을 다시 읽으십시오.

역할은 그 사람이 무엇을 해도 되는지를 말합니다. 어떤 주소에 대해 할 수 있는지는 다른 축이며 openemail.members에 있습니다. 그쪽의 grantAddress와 revokeAddress를 참고하십시오. “메일을 보낼 수 있다”와 “invoices@로 보낼 수 있다”는 서로 다른 문장이며, 지원 담당을 한 명 더 채용한 워크스페이스는 앞의 것은 건드리지 않고 뒤의 것만 바꿉니다.

builtin의 이름이 아니라 editable과 deletable로 분기하십시오. 둘 다 false인 것은 소유자 역할뿐이며, 그 권한 목록은 “내년에 새로 생길 것까지 포함한 모든 권한”으로 저장되는 대신 계산됩니다. 워크스페이스에 기본 제공되는 다섯 개를 포함해 나머지 역할은 모두 두 값이 true입니다. 누군가 이름을 바꾼 역할도 두 값은 정확히 답하지만, 그 이름은 더 이상 아무것도 알려 주지 않습니다.

역할에 묶여 발급된 키는 자신의 스코프와 그 역할의 권한을 교집합한 만큼만 할 수 있으며, 이는 요청마다 경계에서 계산됩니다. 따라서 역할을 좁히면 키를 하나도 회전하지 않고도 그 키들의 권한이 즉시 회수되고, 역할이 없는 키에는 상한이 전혀 없습니다. 즉 null인 역할은 키가 가질 수 있는 가장 좁은 상태가 아니라 가장 넓은 상태입니다.

roles.delete가 키를 옮길 곳을 반드시 요구하는 이유도 같습니다. 키를 고아로 남기면 상한이 통째로 사라져, 그 역할이 제한하고 있던 모든 자격 증명이 조용히 승격됩니다.