SDK

Miembros

`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` y `revokeAddress`.

Todos los métodos

members.ts

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)

Dos concesiones por persona, y no deben fusionarse. role es lo que puede hacer; addresses es aquello sobre lo que puede hacerlo. Ambas tienen que coincidir: un rol con emails:send y access: "viewer" sobre invoices@ es alguien que puede enviar correo y no puede enviarlo desde esa dirección.

Todos los métodos reciben el userId, no el correo. add es la única excepción, y ahí está el motivo de la excepción: quien lo llama tiene una dirección de correo y todavía no un id de usuario, que es justamente la primera mitad de lo que hace esa llamada.

implied: true significa que nadie eligió el rol. La persona tiene direcciones y ninguna fila de rol, así que se dedujo a partir de la concesión más amplia que posee. Trátalo como «aún sin decidir»: update es lo que convierte la inferencia en una decisión. Hasta entonces, ampliar su acceso a direcciones amplía en silencio lo que puede hacer.

El propietario del espacio de trabajo es la primera fila, marcada con isOwner: true, mientras que add, update y remove lo siguen rechazando con member_is_owner. Un espacio de trabajo sin compartir informa de un miembro y no de ninguno, así que excluye isOwner cuando cuentes puestos.

remove actúa sobre los dos ejes: el rol Y todas las concesiones de direcciones en este espacio de trabajo, e informa de addressesRevoked. revokeAddress es el acotado, para alguien que cambió de equipo y no para alguien que se marchó.

Parámetros

emailstringobligatorio: A quién invitar, recortado y en minúsculas. Todavía no necesita una cuenta: se invita a cualquiera, y el rol y las concesiones se aplican cuando acepta. Alguien que ya está en el espacio de trabajo devuelve `member_is_owner` (422).
roleIdstringobligatorio: El rol que tendrá, de 1 a 128 caracteres, y debe ser un rol de este espacio de trabajo: un id desconocido es `role_not_found` (404). El rol de propietario no se puede repartir y devuelve `role_immutable` (409), porque convertir a alguien en propietario es una transferencia del espacio de trabajo y aquí no hay ninguna llamada para eso.
addressIdsstring[]: Direcciones que se entregan en la misma llamada, como máximo 64 ids de 1 a 128 caracteres cada uno; un id que no corresponde a una dirección de este espacio de trabajo se rechaza. El rol se escribe primero y las concesiones lo siguen de una en una, así que un id inválido deja al miembro creado con menos direcciones de las que pediste. La solución es volver a enviar el mismo cuerpo, ya que ambas escrituras hacen upsert.
access'member' | 'viewer': Lo que puede hacer con cada id de `addressIds`: `member` lee la dirección y envía desde ella; `viewer` solo la lee. El valor por defecto es `member`, el nivel que siempre han usado la consola y la antigua vía de compartición, de modo que la misma llamada significa lo mismo desde un script y desde una pantalla; para conceder una combinación, llama después a `grantAddress` para las que difieran.

Respuesta

object'member': Siempre `member`. Una eliminación responde con el mismo valor, su `userId`, `deleted: true` y `addressesRevoked`, y ninguno de los demás campos de abajo.
userIdstring: El id de su cuenta, y el identificador que todas las demás llamadas de miembros reciben en la ruta: get, update, remove y las dos llamadas de direcciones. Añadir a alguien es la única llamada que funciona a partir de un correo, porque quien añade a un compañero conoce su dirección y no su id.
emailstring: El correo de su cuenta, devuelto tal como lo guarda esa fila. Este recurso nunca lo escribe, y la conversión a minúsculas de `add` se aplica a la dirección que envías para la búsqueda, no a lo que vuelve. Después del propietario, la lista de miembros se ordena por él y no por la fecha de incorporación, porque la lista se lee para encontrar a una persona y no para ver qué cambió.
namestring | null: Su nombre visible, tomado de su cuenta, donde la columna es NOT NULL. El null del tipo es defensivo, no un estado que se haya visto producir a esta API. Pertenece a la persona y no al espacio de trabajo, así que nada de este recurso puede establecerlo.
imagestring | null: Su avatar, tomado de su cuenta, y null cuando no ha configurado ninguno.
role.idstring | null: El id del rol que tiene, o null cuando nadie lo eligió. Véase `implied`. Un null aquí es el único caso en el que `role` informa de una inferencia y no de una decisión que alguien tomó.
role.namestring: El nombre del rol. Para un miembro implícito es el nombre de la plantilla integrada a la que se resolvió su acceso, no una fila de este espacio de trabajo.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null: Qué rol integrado es, o null si es personalizado. `owner` aparece únicamente en la fila del propio propietario, junto a `isOwner: true`; asignar ese rol a alguien se rechaza con `role_immutable` (409).
isOwnerboolean: True en exactamente una fila: la cuenta a la que está vinculado el espacio de trabajo. Tiene todos los permisos diga lo que diga su fila de rol, se ordena en primer lugar, y `add`, `update` y `remove` la rechazan con `member_is_owner`. Exclúyela cuando cuentes puestos.
impliedboolean: True cuando esta persona tiene concesiones de direcciones y ninguna fila de miembro, de modo que su rol se dedujo en vez de elegirse: cualquier concesión de `member` se resuelve al rol integrado Member; en caso contrario, Viewer. Nunca es true para el propietario. Muéstralo como «implícito por acceso». Hasta que un PATCH convierta la inferencia en una decisión, ampliar su acceso a direcciones amplía en silencio lo que puede hacer.
permissionsPermission[]: Los permisos del rol aplanados sobre el miembro, de modo que una sola lectura responde a «¿puede hacerlo?» sin tener que obtener el rol. Para un miembro implícito provienen de la TEMPLATE integrada y no de la fila de rol de este espacio de trabajo, así que editar el rol Member integrado no cambia lo que tiene un miembro implícito.
addressesMemberAddress[]: Las direcciones que se le han dado, ordenadas por dirección, cada una con su propio nivel de acceso. Vacío para alguien que tiene un rol y ninguna concesión, que es el aspecto de un miembro nuevo hasta que se le concede una dirección, y es el fallo correcto mientras todavía estás decidiendo qué debería ver.
addresses[].addressIdstring: El id de la dirección, y lo que reciben `grantAddress` y `revokeAddress`. Un id que no corresponde a una dirección de este espacio de trabajo se rechaza en ambos, en lugar de informar de una revocación que nunca ocurrió.
addresses[].addressstring: La dirección completa, en minúsculas, reconstruida a partir de su parte local y su dominio.
addresses[].access'member' | 'viewer': Lo que puede hacer con esta dirección concreta: `member` la lee y envía desde ella; `viewer` solo la lee. Tanto esto como el rol tienen que permitir un envío para que se produzca, así que un rol con `emails:send` sobre una concesión `viewer` no envía desde ninguna dirección; la columna almacenada se llama `role`, y aquí se renombra para que un mismo objeto no lleve dos `role` procedentes de dos vocabularios distintos.
createdAtstring | null: Cuándo se escribió su fila de miembro, en ISO-8601, y null cuando no existe ninguna fila de miembro. Ese null describe el mismo grupo que `implied: true`: personas con direcciones de antes de que existieran los roles y a las que nadie ha asignado un rol desde entonces.