Thành viên
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` và `revokeAddress`.
Mọi phương thức
const people = await openemail.members.list()const member = await openemail.members.get(people[0]!.userId) const sam = await openemail.members.add({ email: '[email protected]', roleId: support.id, addressIds: ['2b81de07-…'], access: 'member',}) await openemail.members.update(sam.userId, { roleId: viewerRoleId }) await openemail.members.grantAddress(sam.userId, { addressId: 'c40a95f2-…', access: 'viewer',})await openemail.members.revokeAddress(sam.userId, 'c40a95f2-…') await openemail.members.remove(sam.userId)Mỗi người có hai loại cấp quyền và không được gộp chúng lại. role là những gì họ được phép làm; addresses là những nơi họ được phép làm điều đó. Cả hai phải đồng thuận: một role có emails:send cùng access: "viewer" trên invoices@ là một người được phép gửi thư nhưng không được phép gửi từ địa chỉ đó.
Mọi phương thức đều nhận userId, không phải email. add là ngoại lệ duy nhất, và đó cũng chính là lý do có ngoại lệ: người gọi nó có một địa chỉ email mà chưa có user id, và đó chính là nửa đầu công việc của lời gọi ấy.
implied: true nghĩa là không ai chọn vai trò đó cả. Họ có các địa chỉ nhưng không có hàng vai trò, nên nó được suy ra từ quyền rộng nhất mà họ đang có. Hãy coi đó là "chưa quyết định", và update là thứ biến suy luận ấy thành một quyết định. Cho tới lúc đó, mở rộng quyền truy cập địa chỉ của họ cũng âm thầm mở rộng những gì họ được phép làm.
Chủ sở hữu workspace là hàng đầu tiên, được đánh dấu isOwner: true, trong khi add, update và remove vẫn từ chối họ với member_is_owner. Một workspace chưa chia sẻ báo cáo một thành viên chứ không phải không có ai, nên hãy loại trừ isOwner khi bạn đếm số chỗ ngồi.
remove xử lý cả hai trục, vai trò VÀ mọi cấp quyền địa chỉ trên workspace này, rồi báo cáo addressesRevoked. revokeAddress là lời gọi hẹp hơn, dành cho người chuyển nhóm chứ không phải người rời đi.
Tham số
emailstringbắt buộc- Mời ai, đã cắt khoảng trắng và viết thường. Người đó chưa cần có tài khoản: ai cũng được mời, và vai trò cùng các cấp quyền sẽ có hiệu lực khi họ chấp nhận. Người đã ở trong workspace thì trả về `member_is_owner` (422).
roleIdstringbắt buộc- Vai trò họ sẽ giữ, 1 đến 128 ký tự, và phải là một vai trò trên workspace này: một id không xác định là `role_not_found` (404). Vai trò owner không thể trao đi và trả về `role_immutable` (409), vì biến ai đó thành chủ sở hữu là một lần chuyển giao workspace, mà ở đây không có lời gọi nào làm việc đó.
addressIdsstring[]- Các địa chỉ cần trao ngay trong cùng lời gọi, tối đa 64 id, mỗi id 1 đến 128 ký tự; một id không phải địa chỉ trên workspace này sẽ bị từ chối. Vai trò được ghi trước rồi các cấp quyền theo sau từng cái một, nên một id sai sẽ để lại một thành viên đã được tạo nhưng có ít địa chỉ hơn bạn yêu cầu. Cách khắc phục là gửi lại đúng body đó, vì cả hai thao tác ghi đều là upsert.
access'member' | 'viewer'- Họ được làm gì với mọi id trong `addressIds`: `member` đọc địa chỉ và gửi dưới danh nghĩa nó, `viewer` chỉ đọc. Mặc định là `member`, đúng mức mà console và đường chia sẻ cũ vẫn luôn dùng, nên cùng một lời gọi mang cùng một ý nghĩa dù từ script hay từ màn hình; muốn cấp mức khác nhau thì gọi `grantAddress` sau đó cho những địa chỉ khác biệt.
Phản hồi
object'member'- Luôn là `member`. Một thao tác xoá cũng trả về đúng giá trị đó, kèm `userId` của họ, `deleted: true` và `addressesRevoked`, và không có trường nào khác bên dưới.
userIdstring- Id tài khoản của họ, và là định danh mà mọi lời gọi thành viên khác nhận trong đường dẫn: get, update, remove và cả hai lời gọi về địa chỉ. Thêm người là lời gọi duy nhất làm việc từ một email, vì người thêm đồng nghiệp biết địa chỉ chứ không biết id của họ.
emailstring- Email trên tài khoản của họ, trả về đúng như hàng dữ liệu đó lưu. Tài nguyên này không bao giờ ghi nó, và việc viết thường trong `add` áp dụng cho địa chỉ bạn gửi lên để tra cứu chứ không cho thứ trả về. Sau chủ sở hữu, danh sách thành viên được sắp theo trường này chứ không theo thời điểm gia nhập, vì danh sách được đọc để tìm một người chứ không phải để xem có gì thay đổi.
namestring | null- Tên hiển thị của họ, lấy từ tài khoản, nơi cột đó là NOT NULL. Giá trị null trong kiểu là để phòng thủ chứ không phải một trạng thái mà API này từng tạo ra. Nó thuộc về họ chứ không thuộc về workspace, nên không gì trên tài nguyên này đặt được nó.
imagestring | null- Ảnh đại diện của họ, lấy từ tài khoản, và null khi họ chưa đặt.
role.idstring | null- Id của vai trò họ giữ, hoặc null khi không ai chọn nó. Xem `implied`. Một null ở đây là trường hợp duy nhất mà `role` báo về một suy luận thay vì một quyết định do ai đó đưa ra.
role.namestring- Tên của vai trò. Với một thành viên suy diễn, đó là tên của template dựng sẵn mà quyền truy cập của họ phân giải tới, không phải một hàng trên workspace này.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- Vai trò này là vai trò dựng sẵn nào, hoặc null với vai trò tự tạo. `owner` chỉ xuất hiện trên chính hàng của chủ sở hữu, cùng với `isOwner: true`; gán vai trò đó cho bất kỳ ai đều bị từ chối với `role_immutable` (409).
isOwnerboolean- True trên đúng một hàng, tài khoản mà workspace được khoá theo. Họ có mọi quyền bất kể hàng vai trò nói gì, họ được sắp đầu tiên, và `add`, `update` cùng `remove` đều từ chối họ với `member_is_owner`. Hãy loại trừ họ khi bạn đếm số chỗ ngồi.
impliedboolean- True khi người này có các cấp quyền địa chỉ mà không có hàng thành viên, nên vai trò của họ được suy ra chứ không phải được chọn: bất kỳ cấp quyền `member` nào cũng phân giải về Member dựng sẵn, còn lại là Viewer. Không bao giờ true với chủ sở hữu. Hãy hiển thị nó là "suy ra từ quyền truy cập". Cho tới khi một PATCH biến suy luận thành quyết định, mở rộng quyền truy cập địa chỉ của họ cũng âm thầm mở rộng những gì họ được phép làm.
permissionsPermission[]- Các quyền của vai trò được làm phẳng lên thành viên, nên một lần đọc đã trả lời được câu "họ có được phép không?" mà không phải tải vai trò về. Với một thành viên suy diễn, các quyền này đến từ TEMPLATE dựng sẵn chứ không phải từ hàng vai trò của workspace này, nên sửa vai trò Member dựng sẵn không làm thay đổi những gì một thành viên suy diễn đang có.
addressesMemberAddress[]- Các địa chỉ họ được trao, sắp theo địa chỉ, mỗi địa chỉ kèm mức truy cập riêng. Rỗng với người có vai trò mà không có cấp quyền nào, đúng hình dạng của một thành viên mới cho tới khi được cấp một địa chỉ, và đó là trạng thái thất bại đúng đắn trong lúc bạn còn đang cân nhắc họ nên thấy những gì.
addresses[].addressIdstring- Id của địa chỉ, và là thứ mà `grantAddress` và `revokeAddress` nhận. Một id không phải địa chỉ trên workspace này sẽ bị từ chối ở cả hai, thay vì báo về một lần thu hồi chưa bao giờ xảy ra.
addresses[].addressstring- Địa chỉ đầy đủ, viết thường, được dựng lại từ phần local và tên miền của nó.
addresses[].access'member' | 'viewer'- Họ được làm gì với riêng địa chỉ này: `member` đọc nó và gửi dưới danh nghĩa nó, `viewer` chỉ đọc. Cả trường này lẫn vai trò đều phải cho phép thì một lần gửi mới diễn ra, nên một vai trò có `emails:send` đè lên một cấp quyền `viewer` sẽ chẳng gửi được từ đâu cả; cột lưu trữ có tên là `role`, và nó được đổi tên ở đây để một đối tượng không mang hai `role` thuộc hai bộ từ vựng khác nhau.
createdAtstring | null- Thời điểm hàng thành viên của họ được ghi, ISO-8601, và null khi hoàn toàn không có hàng thành viên nào. Cái null đó mô tả cùng một nhóm người như `implied: true`: những người có địa chỉ từ trước khi vai trò tồn tại và từ đó chưa được ai gán vai trò.