SDK

Membros

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

Todos os 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)

Duas concessões por pessoa, e não podem ser colapsadas numa só. role é o que podem fazer; addresses é aquilo a que o podem fazer. Ambas têm de concordar: um papel com emails:send e access: "viewer" em invoices@ é alguém que pode enviar correio e não pode enviá-lo a partir desse endereço.

Todos os métodos recebem o userId, não o email. add é a única exceção, e é a razão da exceção: quem a chama tem um endereço de email e ainda nenhum id de utilizador, que é toda a primeira metade do que essa chamada faz.

implied: true significa que ninguém escolheu o papel. Têm endereços e nenhuma linha de papel, por isso foi inferido a partir da concessão mais ampla que possuem. Trate-o como «ainda não decidido», e update é o que transforma a inferência numa decisão. Até lá, alargar o seu acesso a endereços alarga silenciosamente o que podem fazer.

O dono da workspace é a primeira linha, marcada com isOwner: true, enquanto add, update e remove continuam a recusá-lo com member_is_owner. Uma workspace não partilhada reporta um membro em vez de nenhum, por isso exclua isOwner quando estiver a contar lugares.

remove toma ambos os eixos, o papel E todas as concessões de endereço nesta workspace, e reporta addressesRevoked. revokeAddress é o estreito, para alguém que mudou de equipa e não para alguém que saiu.

Parâmetros

emailstringobrigatório: Quem convidar, aparado e passado a minúsculas. Ainda não precisa de conta: toda a gente é convidada, e o papel e as concessões chegam quando aceitam. Alguém que já esteja na workspace é `member_is_owner` (422).
roleIdstringobrigatório: O papel que vão ter, de 1 a 128 caracteres, e tem de ser um papel desta workspace: um id desconhecido é `role_not_found` (404). O papel de dono não pode ser atribuído e volta como `role_immutable` (409), porque tornar alguém dono é uma transferência de workspace e não há aqui nenhuma chamada para isso.
addressIdsstring[]: Endereços a entregar na mesma chamada, no máximo 64 ids de 1 a 128 caracteres cada; um id que não seja um endereço desta workspace é recusado. O papel é escrito primeiro e as concessões seguem uma a uma, por isso um id inválido deixa o membro criado com menos endereços do que pediu. Voltar a publicar o mesmo corpo é a solução, já que ambas as escritas fazem upsert.
access'member' | 'viewer': O que podem fazer com cada id em `addressIds`: `member` lê o endereço e envia como ele, `viewer` apenas o lê. Por omissão `member`, o nível que a consola e o antigo caminho de partilha sempre usaram, para que a mesma chamada signifique o mesmo a partir de um script e de um ecrã; conceda uma mistura chamando `grantAddress` depois para os que diferem.

Resposta

object'member': Sempre `member`. Uma remoção responde com o mesmo valor, o seu `userId`, `deleted: true` e `addressesRevoked`, e nenhum dos outros campos abaixo.
userIdstring: O id da conta deles, e o identificador que todas as outras chamadas de membros recebem no caminho: get, update, remove e ambas as chamadas de endereço. Adicionar alguém é a única chamada que funciona a partir de um email, porque quem adiciona um colega sabe o endereço dele e não o id.
emailstring: O email na conta deles, ecoado tal como essa linha o guarda. Este recurso nunca o escreve, e a passagem a minúsculas em `add` aplica-se ao endereço que envia para a procura e não ao que volta. Depois do dono, a lista de membros é ordenada por ele e não por quando as pessoas entraram, porque a lista é lida para encontrar uma pessoa e não para ver o que mudou.
namestring | null: O nome visível deles, tirado da conta, onde a coluna é NOT NULL. O null no tipo é defensivo e não um estado que esta API tenha sido vista a produzir. Pertence-lhes a eles e não à workspace, por isso nada neste recurso o pode definir.
imagestring | null: O avatar deles, tirado da conta, e null quando não definiram nenhum.
role.idstring | null: O id do papel que têm, ou null quando ninguém o escolheu. Ver `implied`. Um null aqui é o único caso em que `role` reporta uma inferência em vez de uma decisão que alguém tomou.
role.namestring: O nome do papel. Para um membro implícito é o nome do template integrado a que o seu acesso resolveu, não uma linha desta workspace.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null: Qual o papel integrado, ou null para um personalizado. `owner` aparece apenas na linha do próprio dono, ao lado de `isOwner: true`; atribuir esse papel a alguém é recusado com `role_immutable` (409).
isOwnerboolean: True em exatamente uma linha, a conta a que a workspace está associada. Têm todas as permissões independentemente do que diga a sua linha de papel, ordenam-se em primeiro lugar, e `add`, `update` e `remove` recusam-nos todos com `member_is_owner`. Exclua-os quando estiver a contar lugares.
impliedboolean: True quando esta pessoa tem concessões de endereço e nenhuma linha de membro, por isso o seu papel foi inferido em vez de escolhido: qualquer concessão de `member` resolve para o Member integrado, caso contrário Viewer. Nunca true para o dono. Mostre-o como «implícito pelo acesso». Até um PATCH transformar a inferência numa decisão, alargar o seu acesso a endereços alarga silenciosamente o que podem fazer.
permissionsPermission[]: As permissões do papel achatadas sobre o membro, para que uma leitura responda a «podem?» sem ir buscar o papel. Para um membro implícito vêm do TEMPLATE integrado e não da linha de papel desta workspace, por isso editar o papel Member integrado não muda o que um membro implícito tem.
addressesMemberAddress[]: Os endereços que lhes foram dados, ordenados por endereço, cada um com o seu nível de acesso. Vazio para alguém com um papel e nenhuma concessão, que é o aspeto de um novo membro até lhe ser concedido um endereço, e é a falha certa a ter enquanto ainda está a decidir o que devem ver.
addresses[].addressIdstring: O id do endereço, e o que `grantAddress` e `revokeAddress` recebem. Um id que não seja um endereço desta workspace é recusado em ambos, em vez de reportar uma revogação que nunca aconteceu.
addresses[].addressstring: O endereço completo, em minúsculas, reconstruído a partir da sua parte local e do seu domínio.
addresses[].access'member' | 'viewer': O que podem fazer com este endereço em concreto: `member` lê-o e envia como ele, `viewer` apenas o lê. Tanto isto como o papel têm de permitir um envio antes de ele acontecer, por isso um papel com `emails:send` sobre uma concessão `viewer` não envia a partir de nada; a coluna guardada chama-se `role`, e é renomeada aqui para que um objeto não carregue dois `role` tirados de dois vocabulários.
createdAtstring | null: Quando a linha de membro deles foi escrita, ISO-8601, e null quando não existe linha de membro nenhuma. Esse null descreve a mesma população que `implied: true`: pessoas que têm endereços de antes de os papéis existirem e a quem ninguém deu um papel desde então.