SDK
Membres
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` et `revokeAddress`.
Toutes les méthodes
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)Deux attributions par personne, et elles ne doivent pas être confondues. role, c'est ce qu'elle a le droit de faire ; addresses, c'est ce sur quoi elle a le droit de le faire. Les deux doivent concorder : un rôle portant emails:send avec access: "viewer" sur invoices@ désigne quelqu'un qui peut envoyer du courrier et qui ne peut pas en envoyer depuis cette adresse.
Chaque méthode prend le userId, pas l'e-mail. add est la seule exception, et c'en est la raison : son appelant dispose d'une adresse e-mail et pas encore d'un id d'utilisateur, ce qui constitue toute la première moitié de ce que fait cet appel.
implied: true signifie que personne n'a choisi le rôle. La personne détient des adresses et aucune ligne de rôle : il a donc été déduit de l'attribution la plus large qu'elle possède. Traitez-le comme « pas encore décidé » ; c'est update qui transforme la déduction en décision. D'ici là, élargir son accès aux adresses élargit silencieusement ce qu'elle a le droit de faire.
Le propriétaire du workspace est la première ligne, marquée isOwner: true, tandis qu'add, update et remove le refusent toujours avec member_is_owner. Un workspace non partagé rapporte un membre et non zéro : excluez donc isOwner quand vous comptez des sièges.
remove agit sur les deux axes, le rôle ET chaque attribution d'adresse sur ce workspace, et rapporte addressesRevoked. revokeAddress est l'appel étroit, pour quelqu'un qui a changé d'équipe plutôt que pour quelqu'un qui est parti.
Paramètres
emailstringobligatoire- Qui inviter, nettoyé des espaces et mis en minuscules. La personne n'a pas encore besoin d'un compte : tout le monde est invité, et le rôle et les attributions se posent à l'acceptation. Quelqu'un qui est déjà dans le workspace donne `member_is_owner` (422).
roleIdstringobligatoire- Le rôle qu'elle détiendra, de 1 à 128 caractères, et ce doit être un rôle de ce workspace : un id inconnu donne `role_not_found` (404). Le rôle owner ne peut pas être distribué et revient en `role_immutable` (409), car faire de quelqu'un un propriétaire est un transfert de workspace, et il n'existe pas d'appel pour cela ici.
addressIdsstring[]- Les adresses à transmettre dans le même appel, au maximum 64 ids de 1 à 128 caractères chacun ; un id qui n'est pas une adresse de ce workspace est refusé. Le rôle est écrit en premier et les attributions suivent une à une : un id erroné laisse donc le membre créé avec moins d'adresses que demandé. La solution est de reposter le même corps, puisque les deux écritures font un upsert.
access'member' | 'viewer'- Ce qu'elle peut faire avec chaque id de `addressIds` : `member` lit l'adresse et envoie depuis elle, `viewer` se contente de la lire. `member` par défaut, le niveau qu'ont toujours utilisé la console et l'ancien chemin de partage, pour que le même appel signifie la même chose depuis un script et depuis un écran ; pour panacher, appelez ensuite `grantAddress` sur celles qui diffèrent.
Réponse
object'member'- Toujours `member`. Une suppression répond avec la même valeur, le `userId` de la personne, `deleted: true` et `addressesRevoked`, et aucun des autres champs ci-dessous.
userIdstring- L'id de son compte, et le handle que prend dans le chemin tout autre appel members : get, update, remove et les deux appels d'adresse. Ajouter quelqu'un est le seul appel qui fonctionne à partir d'un e-mail, car celui qui ajoute un collègue connaît son adresse et pas son id.
emailstring- L'e-mail de son compte, renvoyé tel que cette ligne le stocke. Cette ressource ne l'écrit jamais, et la mise en minuscules d'`add` s'applique à l'adresse que vous envoyez pour la recherche, pas à ce qui revient. Après le propriétaire, la liste des membres est triée dessus plutôt que sur la date d'arrivée des personnes, car on lit cette liste pour trouver quelqu'un, pas pour voir ce qui a changé.
namestring | null- Son nom affiché, repris de son compte, où la colonne est NOT NULL. Le null présent dans le type est défensif plutôt qu'un état que cette API ait été vue produire. Il lui appartient plutôt qu'au workspace : rien sur cette ressource ne peut donc le définir.
imagestring | null- Son avatar, repris de son compte, et null quand elle n'en a pas défini.
role.idstring | null- L'id du rôle qu'elle détient, ou null quand personne ne l'a choisi. Voir `implied`. Un null ici est le seul cas où `role` rapporte une déduction plutôt qu'une décision prise par quelqu'un.
role.namestring- Le nom du rôle. Pour un membre implicite, c'est le nom du modèle intégré vers lequel son accès s'est résolu, pas une ligne de ce workspace.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- De quel rôle intégré il s'agit, ou null pour un rôle personnalisé. `owner` n'apparaît que sur la ligne du propriétaire lui-même, aux côtés d'`isOwner: true` ; attribuer ce rôle à quiconque est refusé avec `role_immutable` (409).
isOwnerboolean- Vrai sur exactement une ligne, le compte sur lequel le workspace est indexé. Cette personne détient toutes les permissions quoi que dise sa ligne de rôle, elle est triée en premier, et `add`, `update` et `remove` la refusent tous avec `member_is_owner`. Excluez-la quand vous comptez des sièges.
impliedboolean- Vrai quand cette personne a des attributions d'adresses et aucune ligne de membre : son rôle a donc été déduit plutôt que choisi, toute attribution `member` se résolvant vers le rôle Member intégré, sinon vers Viewer. Jamais vrai pour le propriétaire. Affichez-le comme « déduit de l'accès ». Tant qu'un PATCH n'a pas transformé la déduction en décision, élargir son accès aux adresses élargit silencieusement ce qu'elle a le droit de faire.
permissionsPermission[]- Les permissions du rôle aplaties sur le membre, pour qu'une seule lecture réponde à « a-t-elle le droit ? » sans aller chercher le rôle. Pour un membre implicite, elles viennent du MODÈLE intégré plutôt que de la ligne de rôle de ce workspace : modifier le rôle Member intégré ne change donc pas ce que détient un membre implicite.
addressesMemberAddress[]- Les adresses qui lui ont été accordées, triées par adresse, chacune avec son propre niveau d'accès. Vide pour quelqu'un qui détient un rôle et aucune attribution, ce à quoi ressemble un nouveau membre tant qu'aucune adresse ne lui est accordée, et c'est le bon échec à avoir pendant que vous décidez encore de ce qu'elle doit voir.
addresses[].addressIdstring- L'id de l'adresse, et ce que prennent `grantAddress` et `revokeAddress`. Un id qui n'est pas une adresse de ce workspace est refusé sur les deux, plutôt que de rapporter une révocation qui n'a jamais eu lieu.
addresses[].addressstring- L'adresse complète, en minuscules, reconstruite à partir de sa partie locale et de son domaine.
addresses[].access'member' | 'viewer'- Ce qu'elle peut faire avec cette seule adresse : `member` la lit et envoie depuis elle, `viewer` se contente de la lire. Ce champ et le rôle doivent tous deux autoriser un envoi pour qu'il ait lieu : un rôle portant `emails:send` par-dessus une attribution `viewer` n'envoie depuis rien du tout. La colonne stockée s'appelle `role`, et elle est renommée ici pour qu'un même object ne porte pas deux `role` tirés de deux vocabulaires.
createdAtstring | null- Quand sa ligne de membre a été écrite, en ISO-8601, et null quand il n'existe aucune ligne de membre. Ce null décrit la même population qu'`implied: true` : les personnes qui détiennent des adresses datant d'avant l'existence des rôles et à qui personne n'a depuis attribué de rôle.