Membres
`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address`, ainsi que les méthodes d'invitation à côté.
Toutes les méthodes
support_role_id = "role_8b1f4c2e9a7d3b60e5f1a2c4"viewer_role_id = "role_2c7e9a1f4b8d3e60c5a7f1b9" invitation = client.members.add( email: "[email protected]", roleId: support_role_id, addressIds: ["2b81de07-9c3f-4a61-b8e2-5d07f4c19a36"], access: "member")puts invitation[:id], invitation[:expiresAt] people = client.members.list_allputs people.map { |person| "#{person[:email]} #{person[:userId]}" } sam_id = "q7Vd3kX9mT2pLw8RzN4bYc6HfJ1sGa5E"member = client.members.get(sam_id)puts member.dig(:role, :name), member[:implied] client.members.update(sam_id, roleId: viewer_role_id) address_id = "c40a95f2-1e7b-4d38-a6c9-82f05b3d7e14"client.members.grant_address(sam_id, addressId: address_id, access: "viewer")client.members.revoke_address(sam_id, address_id) removed = client.members.remove(sam_id)puts removed[:addressesRevoked]Deux attributions par personne, et elles ne doivent pas être confondues. role est ce qu'elle a le droit de faire. addresses est ce sur quoi elle a le droit de le faire. Les deux doivent concorder : un rôle qui détient emails:send avec access: "viewer" sur invoices@ désigne quelqu'un qui peut envoyer du courrier mais pas depuis cette adresse. L'exception est un rôle qui détient addresses:all, qui atteint toutes les adresses quoi que liste addresses, car cet Array ne contient que les attributions directes. Vérifiez donc permissions avant de lire addresses comme la totalité de ce que quelqu'un peut atteindre.
Chaque appel qui concerne une personne prend son userId comme premier argument, et non son e-mail : lisez-le donc dans list ou list_all, comme le fait l'exemple. add est la seule exception, car il invite une adresse : la personne n'a de userId qu'une fois l'invitation acceptée, et list_invitations suit l'invitation jusque-là. Les champs d'un corps de requête gardent les noms en camelCase de l'API (roleId:, addressIds:, addressId:), passés en mots-clés ou en un seul Hash.
list renvoie une OpenEmail::Page, list_all renvoie tous les membres dans un seul Array, et iterate passe chaque membre à un bloc ou renvoie un Enumerator sans bloc. Un membre revient sous forme de Hash à clés Symbol, et role est un Hash à l'intérieur : member.dig(:role, :name) lit donc le nom du rôle.
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 de l'espace de travail est la première ligne, marquée isOwner: true, tandis qu'add, update et remove le refusent toujours avec member_is_owner, un 422 levé sous forme d'OpenEmail::ValidationError. Un espace de travail non partagé indique un membre et non zéro. Excluez donc isOwner quand vous comptez les sièges : client.members.list_all.count { |member| !member[:isOwner] }.
remove agit sur les deux axes, le rôle ET chaque attribution d'adresse de cet espace de travail, et indique addressesRevoked. revoke_address est l'appel ciblé, 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 que la personne détiendra, de 1 à 128 caractères, et ce doit être un rôle de cet espace de travail : un id inconnu donne `role_not_found` (404), levé sous forme d'`OpenEmail::NotFoundError`. Le rôle propriétaire ne peut pas être attribué et revient en `role_immutable` (409), car faire de quelqu'un un propriétaire est un transfert d'espace de travail, et aucun appel ici ne le permet.
addressIdsArray<String>- Les adresses que porte l'invitation, au maximum 64 ids de 1 à 128 caractères chacun, attribuées lorsqu'elle est acceptée. Chaque id est vérifié avant toute écriture : un id qui n'est pas une adresse de ce workspace fait donc refuser l'appel entier avec 422 `member_not_found`, et rien n'est envoyé. Inviter de nouveau la même adresse dans les dix minutes donne 409 `invitation_too_soon`.
accessString- Ce que la personne peut faire avec chaque id de `addressIds` : `member` lit l'adresse et envoie en son nom, `viewer` se contente de la lire. Vaut `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 `grant_address` sur les adresses qui diffèrent.
Réponse
objectString- 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, que tout autre appel sur les membres prend comme premier argument : `get`, `update`, `remove` et les deux appels d'adresse. Ajouter quelqu'un est le seul appel qui part plutôt d'un e-mail, car celui qui ajoute un collègue connaît son adresse et non 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 or nil- Son nom affiché, repris de son compte, où la colonne a toujours une valeur. Le nil du type est une précaution plutôt qu'un état que cette API ait déjà produit. Ce nom appartient à la personne et non à l'espace de travail : rien sur cette ressource ne peut donc le définir.
imageString or nil- Son avatar, repris de son compte, et nil quand la personne n'en a pas défini.
role.idString or nil- L'id du rôle que la personne détient, lu avec `member.dig(:role, :id)`, ou nil quand personne ne l'a choisi. Voir `implied`. Un nil ici est le seul cas où `role` indique 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é auquel correspond son accès, et non une ligne de cet espace de travail.
role.builtinString or nil- De quel rôle intégré il s'agit, `owner`, `admin`, `member`, `viewer`, `developer` ou `billing`, ou nil 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- True 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` en fait le rôle intégré Member, sinon Viewer. Jamais true pour le propriétaire. Affichez-le comme « déduit de l'accès ». Tant qu'un `update` n'a pas transformé la déduction en décision, élargir son accès aux adresses élargit en silence ce qu'elle peut faire.
permissionsArray<String>- Les permissions du rôle reportées 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 cet espace de travail : modifier le rôle Member intégré ne change donc pas ce que détient un membre implicite.
addressesArray<Hash>- 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 `grant_address` et `revoke_address`. Un id qui n'est pas une adresse de cet espace de travail est refusé par les deux, plutôt que de signaler 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[].accessString- Ce que la personne peut faire avec cette adresse précise : `member` la lit et envoie en son nom, `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 qui détient `emails:send` avec une attribution `viewer` n'envoie depuis aucune adresse. La colonne stockée s'appelle `role`, et elle est renommée ici pour qu'un même Hash ne porte pas deux clés `role` issues de deux vocabulaires.
createdAtString or nil- Quand sa ligne de membre a été écrite, sous forme de String ISO 8601, et nil quand il n'existe aucune ligne de membre. Ce nil 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.
Invitations
waiting = client.members.list_all_invitations waiting.each do |invitation| client.members.resend_invitation(invitation[:id]) if invitation[:expired]end client.members.revoke_invitation("winv_6bb640f5b99e47deb758f1f5")add répond par une invitation, et voici les appels qui en assurent le suivi. list_invitations renvoie une OpenEmail::Page de celles que personne n'a encore acceptées, list_all_invitations les renvoie toutes dans un seul Array, et iterate_invitations passe chacune à un bloc ou renvoie un Enumerator. resend_invitation en renvoie une avec un nouveau lien et quatorze jours de plus, et revoke_invitation la retire. Une invitation en attente n'accorde rien tant qu'elle n'est pas acceptée.
resend_invitation refuse la même adresse deux fois en dix minutes avec 409 invitation_too_soon, et revoke_invitation refuse une invitation acceptée entre-temps avec 409 invitation_accepted. Les deux sont levés sous forme d'OpenEmail::ConflictError : conflict? vaut donc true et code les distingue.