SDK
Membres
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` i `revokeAddress`.
Tots els mètodes
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)Dues concessions per persona, i no s'han de fusionar. role és el que poden fer; addresses és allò sobre què ho poden fer. Totes dues han de coincidir: un rol amb emails:send i access: "viewer" sobre invoices@ és algú que pot enviar correu i que no el pot enviar des d'aquella adreça.
Tots els mètodes prenen el userId, no el correu. add és l'única excepció, i n'és el motiu: qui la crida té una adreça de correu i encara cap id d'usuari, que és tota la primera meitat del que fa aquesta crida.
implied: true vol dir que ningú no ha triat el rol. Tenen adreces i cap fila de rol, de manera que es va inferir a partir de la concessió més àmplia que tenen. Tracta-ho com a «encara no decidit», i update és el que converteix la inferència en una decisió. Fins llavors, ampliar-los l'accés a adreces amplia silenciosament el que poden fer.
El propietari de l'espai de treball és la primera fila, marcada amb isOwner: true, mentre que add, update i remove el rebutgen igualment amb member_is_owner. Un espai de treball no compartit informa d'un membre en lloc de cap, així que exclou isOwner quan comptis llicències.
remove actua sobre tots dos eixos, el rol I totes les concessions d'adreça d'aquest espai de treball, i informa d'addressesRevoked. revokeAddress és l'estret, per a algú que ha canviat d'equip i no pas per a algú que ha marxat.
Paràmetres
emailstringobligatori- A qui convidar, retallat i en minúscules. Encara no cal que tingui compte: tothom és convidat, i el rol i les concessions s'apliquen quan accepta. Algú que ja és a l'espai de treball és `member_is_owner` (422).
roleIdstringobligatori- El rol que tindrà, d'1 a 128 caràcters, i ha de ser un rol d'aquest espai de treball: un id desconegut és `role_not_found` (404). El rol de propietari no es pot repartir i torna `role_immutable` (409), perquè fer algú propietari és una transferència de l'espai de treball i aquí no hi ha cap crida per a això.
addressIdsstring[]- Adreces per lliurar a la mateixa crida, com a màxim 64 ids d'entre 1 i 128 caràcters cadascun; un id que no sigui una adreça d'aquest espai de treball es rebutja. El rol s'escriu primer i les concessions el segueixen d'una en una, de manera que un id incorrecte deixa el membre creat amb menys adreces de les que havies demanat. Tornar a enviar el mateix cos és la solució, ja que totes dues escriptures fan upsert.
access'member' | 'viewer'- El que pot fer amb cada id d'`addressIds`: `member` llegeix l'adreça i hi envia com a tal, `viewer` només la llegeix. Per defecte és `member`, el nivell que sempre han fet servir la consola i el camí de compartició antic, de manera que la mateixa crida vol dir el mateix des d'un script i des d'una pantalla; concedeix una barreja cridant després `grantAddress` per a les que difereixin.
Resposta
object'member'- Sempre `member`. Una eliminació respon amb el mateix valor, el seu `userId`, `deleted: true` i `addressesRevoked`, i cap dels altres camps de sota.
userIdstring- L'id del seu compte, i l'identificador que totes les altres crides de membres prenen a la ruta: get, update, remove i les dues crides d'adreces. Afegir algú és l'única crida que funciona a partir d'un correu, perquè qui afegeix un company sap la seva adreça i no el seu id.
emailstring- El correu del seu compte, reproduït tal com el desa aquella fila. Aquest recurs no l'escriu mai, i el pas a minúscules d'`add` s'aplica a l'adreça que envies per a la cerca i no pas al que torna. Després del propietari, la llista de membres s'ordena per aquest camp i no per quan s'hi va incorporar cadascú, perquè la llista es llegeix per trobar una persona i no per veure què ha canviat.
namestring | null- El seu nom visible, pres del seu compte, on la columna és NOT NULL. El null del tipus és defensiu i no pas un estat que s'hagi vist produir en aquesta API. Els pertany a ells i no a l'espai de treball, de manera que res d'aquest recurs no el pot establir.
imagestring | null- El seu avatar, pres del seu compte, i null quan no n'ha posat cap.
role.idstring | null- L'id del rol que té, o null quan ningú no l'ha triat. Consulta `implied`. Un null aquí és l'únic cas en què `role` informa d'una inferència i no d'una decisió que hagi pres algú.
role.namestring- El nom del rol. Per a un membre implícit és el nom de la plantilla integrada a què s'ha resolt el seu accés, no pas una fila d'aquest espai de treball.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- Quin rol integrat és, o null si és personalitzat. `owner` només apareix a la fila del propietari mateix, al costat d'`isOwner: true`; assignar aquest rol a qualsevol persona es rebutja amb `role_immutable` (409).
isOwnerboolean- Cert exactament en una fila, el compte sobre el qual està indexat l'espai de treball. Té tots els permisos digui el que digui la seva fila de rol, s'ordena primer, i `add`, `update` i `remove` el rebutgen tots amb `member_is_owner`. Exclou-lo quan comptis llicències.
impliedboolean- Cert quan aquesta persona té concessions d'adreça i cap fila de membre, de manera que el seu rol s'ha inferit en lloc de triar-se: qualsevol concessió de `member` es resol al Member integrat, i si no al Viewer. Mai no és cert per al propietari. Mostra-ho com a «implícit per l'accés». Fins que un PATCH converteixi la inferència en una decisió, ampliar-li l'accés a adreces amplia silenciosament el que pot fer.
permissionsPermission[]- Els permisos del rol aplanats sobre el membre, de manera que una sola lectura respon «pot fer-ho?» sense haver d'obtenir el rol. Per a un membre implícit provenen de la PLANTILLA integrada i no de la fila de rol d'aquest espai de treball, de manera que editar el rol Member integrat no canvia el que té un membre implícit.
addressesMemberAddress[]- Les adreces que se li han concedit, ordenades per adreça, cadascuna amb el seu propi nivell d'accés. Buit per a algú que té un rol i cap concessió, que és l'aspecte d'un membre nou fins que se li concedeix una adreça, i és la fallada correcta mentre encara estàs decidint què ha de veure.
addresses[].addressIdstring- L'id de l'adreça, i el que prenen `grantAddress` i `revokeAddress`. Un id que no sigui una adreça d'aquest espai de treball es rebutja a totes dues, en lloc d'informar d'una revocació que no s'ha produït mai.
addresses[].addressstring- L'adreça completa, en minúscules, reconstruïda a partir de la seva part local i el seu domini.
addresses[].access'member' | 'viewer'- El que pot fer amb aquesta adreça concreta: `member` la llegeix i hi envia com a tal, `viewer` només la llegeix. Tant això com el rol han de permetre un enviament perquè se'n produeixi cap, de manera que un rol amb `emails:send` sobre una concessió `viewer` no envia des de res; la columna emmagatzemada es diu `role`, i aquí es reanomena perquè un mateix objecte no porti dos `role` procedents de dos vocabularis.
createdAtstring | null- Quan es va escriure la seva fila de membre, ISO-8601, i null quan no hi ha cap fila de membre. Aquest null descriu la mateixa població que `implied: true`: gent que té adreces d'abans que existissin els rols i a qui ningú no ha donat cap rol des d'aleshores.