Bỏ qua tới phần tài liệu
SDK

Vai trò

`roles.list`, `get`, `create`, `update`, `delete` và `listPermissions`.

Tất cả phương thức

roles.ts
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 chứa sáu mục, không phải ba: emails:send kéo theo emails:read, threads:write kéo theo threads:readlabels:write kéo theo labels:read. Hãy đọc lại danh sách thay vì phỏng đoán.

Vai trò cho biết một người được phép LÀM gì. Họ được làm điều đó với những ĐỊA CHỈ nào là trục còn lại, và nằm ở openemail.members. Xem grantAddressrevokeAddress ở đó. “Được gửi thư” và “được gửi với tư cách invoices@” là hai câu khác nhau, và một không gian làm việc thuê thêm nhân viên hỗ trợ thứ hai sẽ thay đổi câu thứ hai mà không động đến câu thứ nhất.

Hãy rẽ nhánh theo editabledeletable thay vì theo tên của builtin. Cả hai chỉ là false đối với riêng vai trò chủ sở hữu, vốn có danh sách là “mọi quyền, kể cả những quyền được tạo ra vào năm sau” và được tính toán chứ không được lưu trữ; mọi vai trò khác đều trả về true cho cả hai, kể cả năm vai trò được khởi tạo sẵn cho một không gian làm việc. Một vai trò đã bị ai đó đổi tên vẫn trả lời đúng cả hai, còn tên của nó thì không còn cho bạn biết điều gì.

update THAY THẾ danh sách quyền. Không có lệnh gọi cấp từng quyền một, vì vậy hãy đọc vai trò, thay đổi mục bạn muốn rồi gửi lại toàn bộ. Nếu chỉ gửi một quyền, vai trò sẽ chỉ giữ đúng quyền đó, cộng với những quyền mà nó bao hàm.

delete cần reassignTo ngay khi có bất kỳ ai đang giữ vai trò đó, và tham số này được truyền dưới dạng query parameter vì phần body của DELETE bị nhiều runtime và một số proxy loại bỏ. Kết quả báo cáo reassignedkeysReassigned riêng biệt, để script có thể ghi log những gì nó thực sự đã làm thay vì những gì nó đã yêu cầu.

listPermissions()GET /roles/permissions, một đường dẫn cố định nằm đúng vị trí của id vai trò. Client mã hóa cứng đường dẫn này thay vì truyền chuỗi qua get, nên việc yêu cầu một vai trò thực sự có tên “permissions” sẽ là yêu cầu một vai trò và nhận về 404, đó là câu trả lời trung thực cho những gì đã được nhập. scope: false đánh dấu những mục mà không khóa nào có thể nắm giữ.

Vai trò là giới hạn trên của khóa

Một khóa được cấp gắn với một vai trò chỉ có thể thực hiện các scope của chính nó GIAO với các quyền của vai trò đó, được xác định theo từng yêu cầu tại ranh giới. Vì vậy, việc thu hẹp một vai trò sẽ thu hồi quyền của các khóa ngay lập tức mà không cần xoay vòng khóa nào, còn một khóa không có vai trò thì hoàn toàn không có giới hạn trên, khiến vai trò null trở thành trạng thái rộng nhất mà một khóa có thể có, chứ không phải hẹp nhất.

Đó cũng là lý do roles.delete bắt buộc phải có nơi để chuyển các khóa sang. Để chúng mồ côi sẽ xóa bỏ hoàn toàn giới hạn trên của chúng, âm thầm nâng quyền mọi thông tin xác thực mà vai trò đó đang giới hạn.

GET /keys/selfGET /ping báo cáo roleIdgrantedScopes bên cạnh scopes có hiệu lực; đó là cách trả lời câu hỏi “khóa của tôi có emails:send mà tôi vẫn nhận insufficient_scope”: bất cứ thứ gì có trong grantedScopes mà thiếu trong scopes đều đã bị vai trò lấy đi. openemail.me.get()openemail.me.ping() trả về cả hai, có kiểu dữ liệu.

Tham số

namestringbắt buộc
Tên mà không gian làm việc đặt cho vai trò: từ 1 đến 48 ký tự, được cắt khoảng trắng trước khi lưu. Tên là duy nhất trong mỗi không gian làm việc, không phân biệt chữ hoa chữ thường, nên một "Support" thứ hai sẽ bị từ chối với `role_name_taken` (409) thay vì được tạo bên cạnh cái đầu tiên.
descriptionstring
Một câu mô tả mục đích của vai trò, được cắt khoảng trắng và tối đa 240 ký tự. Chuỗi trống sau khi cắt khoảng trắng được lưu là null, nên một mô tả chỉ gồm khoảng trắng sẽ được trả về là null thay vì như những gì bạn đã gửi.
permissionsPermission[]bắt buộc
Những gì vai trò cấp, lấy từ bộ từ vựng mà `listPermissions()` cung cấp; một chuỗi không có trong đó sẽ gây lỗi 422 trên `permissions` thay vì bị âm thầm bỏ qua, nên lỗi đánh máy được báo ngay thay vì khiến bạn mất cả buổi chiều. Danh sách được MỞ RỘNG khi nhận vào (`templates:write` sẽ lưu thêm `templates:read` bên cạnh), loại bỏ trùng lặp và sắp xếp lại theo thứ tự chuẩn, vì vậy hãy đọc danh sách đã lưu từ phản hồi thay vì cho rằng nó giống hệt danh sách bạn đã gửi.

Phản hồi

object'role'
Luôn là `role`. Bản ghi tombstone khi xóa trả về cùng giá trị này, `id` của vai trò, `deleted: true` và hai số đếm chuyển giao, và không có trường nào khác bên dưới.
idstring
Id của vai trò. Đây là giá trị mà `roleId` của thành viên tham chiếu, là thứ mà giới hạn trên của khóa API trỏ tới, và là giá trị `reassignTo` nhận khi vai trò này bị xóa.
namestring
Tên mà không gian làm việc đặt cho vai trò, đã được cắt khoảng trắng và là duy nhất không phân biệt chữ hoa chữ thường. Mọi vai trò trừ vai trò của chủ sở hữu đều có thể đổi tên, kể cả các vai trò được khởi tạo sẵn (`builtin` cho biết hàng đến từ đâu, chứ không phải nó buộc phải giữ tên gì), vì vậy đừng coi "Admin" là lời đảm bảo về những gì vai trò đó nắm giữ. Tên đã được một vai trò khác sử dụng sẽ trả về `role_name_taken` (409, `param: "name"`); đổi tên vai trò chủ sở hữu sẽ trả về `role_immutable` (409), giống như mọi chỉnh sửa khác đối với nó.
descriptionstring | null
Câu mô tả vai trò, hoặc null nếu không được cung cấp. Đầu vào trống được lưu là null ở cả thao tác tạo lẫn cập nhật, nên giá trị này không bao giờ là chuỗi rỗng.
permissionsPermission[]
Mọi quyền mà vai trò cấp, đã được mở rộng và theo thứ tự chuẩn thay vì theo thứ tự ai đó đã nhập. Thứ tự này rất quan trọng: hai vai trò có cùng các quyền sẽ bằng nhau khi so sánh dưới dạng JSON, nhờ đó màn hình cài đặt có thể so sánh khác biệt giữa chúng để quyết định có bật nút Lưu hay không.
builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null
Hàng này đến từ vai trò nào trong sáu vai trò khởi tạo sẵn, hoặc null nếu vai trò do không gian làm việc tự tạo. Trường này ghi lại nguồn khởi tạo chứ không phải trạng thái: vai trò khởi tạo sẵn vẫn có thể được đổi tên, đổi quyền và xóa như mọi vai trò khác. Hãy rẽ nhánh theo `editable` và `deletable` thay vì theo trường này. Một vai trò được ai đó đặt tên "Admin" không nhất thiết là vai trò khởi tạo sẵn, và vai trò khởi tạo sẵn có thể không còn mang tên đó nữa.
editableboolean
Được tính bằng `builtin !== 'owner'`, nên chỉ false đối với riêng vai trò chủ sở hữu và mọi PATCH lên vai trò đó đều bị từ chối với `role_immutable` (409). Mọi vai trò khác đều có thể chỉnh sửa toàn bộ (tên, mô tả và quyền), kể cả năm vai trò được khởi tạo sẵn cho không gian làm việc.
deletableboolean
Được tính bằng `builtin !== 'owner'`: false đối với riêng vai trò chủ sở hữu, vốn trả về `role_undeletable` (409), và true đối với mọi vai trò khác kể cả các vai trò khởi tạo sẵn. Hãy kiểm tra trường này trước khi hiển thị nút thay vì sau khi bị từ chối, tuy nhiên một vai trò vẫn còn người nắm giữ cũng cần `reassignTo`, nếu không thao tác xóa sẽ trả về `role_in_use` (409).
membersnumber
Số người đang giữ vai trò này, được đếm từ các hàng thành viên của không gian làm việc. Chủ sở hữu không nằm trong số đó: họ không có hàng thành viên và không thể được gán vai trò, nên vai trò Owner báo cáo không có người nắm giữ nào dù danh sách thành viên vẫn hiển thị họ.
apiKeysnumber
Số khóa API còn hiệu lực bị vai trò này giới hạn; các khóa đã thu hồi không được tính, tuy nhiên thao tác xóa sẽ trỏ lại mọi hàng khóa đang trỏ đến vai trò, kể cả các khóa đã thu hồi. Đây là nhóm thứ hai phải được chuyển đi trước khi có thể xóa vai trò, và là nhóm không ai để ý: khóa là chương trình, và chương trình thì không phàn nàn.
createdAtstring
Thời điểm hàng vai trò được ghi, theo ISO-8601. Các hàng dựng sẵn được khởi tạo lười (lazily) vào lần đầu tiên có thứ gì đó cần đến chúng, chẳng hạn một lần đọc danh sách vai trò, một lần tạo vai trò hoặc màn hình khóa API, thay vì lúc tạo không gian làm việc, nên dấu thời gian của một vai trò dựng sẵn là lúc yêu cầu đầu tiên đó đến chứ không phải lúc không gian làm việc được tạo.
updatedAtstring
Thời điểm vai trò thay đổi lần cuối, theo ISO-8601. Mọi PATCH được chấp nhận đều cập nhật giá trị này, kể cả PATCH đặt một trường về đúng giá trị nó đang có.