Saltar para a documentação
Python

Membros

`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address` e os métodos de convites ao lado.

Todos os métodos

members.py
from openemail import openemail roles = openemail.roles.list_all()support = next(role for role in roles if role['name'] == 'Support')viewer = next(role for role in roles if role['builtin'] == 'viewer') invitation = openemail.members.add({    'email': '[email protected]',    'roleId': support['id'],    'addressIds': ['2b81de07-…'],    'access': 'member',}) people = openemail.members.list_all()sam = next(person for person in people if person['email'] == '[email protected]')member = openemail.members.get(sam['userId']) openemail.members.update(sam['userId'], {'roleId': viewer['id']}) openemail.members.grant_address(sam['userId'], {    'addressId': 'c40a95f2-…',    'access': 'viewer',})openemail.members.revoke_address(sam['userId'], 'c40a95f2-…') 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. A exceção é um papel com addresses:all, que alcança todos os endereços seja o que for que addresses liste, porque essa lista só tem concessões diretas, por isso verifique permissions antes de a ler como todo o alcance de alguém.

Todos os métodos recebem o userId, não o email. add é a única exceção, porque convida um endereço: a pessoa só tem um userId depois de aceitar, e list_invitations acompanha o convite até lá.

'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. revoke_address é o estreito, para alguém que mudou de equipa e não para alguém que saiu.

Parâmetros

emailstrobrigató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).
roleIdstrobrigató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.
addressIdslist[str]
Endereços que o convite transporta, no máximo 64 ids de 1 a 128 caracteres cada, concedidos quando é aceite. Cada id é verificado antes de qualquer escrita, por isso um que não seja um endereço desta workspace faz recusar a chamada inteira com 422 `member_not_found` e nada é enviado. Convidar o mesmo endereço outra vez dentro de dez minutos é 409 `invitation_too_soon`.
accessLiteral['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 `grant_address` depois para os que diferem.

Resposta

objectLiteral['member']
Sempre `member`. Uma remoção responde com o mesmo valor, o seu `userId`, `'deleted': True` e `addressesRevoked`, e nenhum dos outros campos abaixo.
userIdstr
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.
emailstr
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.
namestr | None
O nome de apresentação da pessoa, tirado da conta dela, onde a coluna é NOT NULL. O `None` no tipo é defensivo e não um estado que esta API tenha sido vista a produzir. Pertence à pessoa e não ao espaço de trabalho, por isso nada neste recurso o pode definir.
imagestr | None
O avatar deles, tirado da conta, e null quando não definiram nenhum.
role.idstr | None
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.namestr
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.builtinLiteral['owner', 'admin', 'member', 'viewer', 'developer', 'billing'] | None
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).
isOwnerbool
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.
impliedbool
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.
permissionslist[Permission]
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.
addresseslist[MemberAddressResource]
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[].addressIdstr
O id do endereço, e o que `grant_address` e `revoke_address` 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[].addressstr
O endereço completo, em minúsculas, reconstruído a partir da sua parte local e do seu domínio.
addresses[].accessLiteral['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.
createdAtstr | None
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.

Convites

invitations.py
from openemail import openemail waiting = openemail.members.list_all_invitations() for invitation in waiting:    if invitation['expired']:        openemail.members.resend_invitation(invitation['id']) openemail.members.revoke_invitation('winv_6bb640f5b99e47deb758f1f5')

add responde com um convite, e estas são as chamadas que lhe dão seguimento: list_invitations, list_all_invitations e iterate_invitations leem os que ninguém aceitou ainda, resend_invitation volta a enviar um com uma nova ligação e mais catorze dias, e revoke_invitation retira-o. Um convite pendente não concede nada até ser aceite.

resend_invitation recusa o mesmo endereço duas vezes em dez minutos com 409 invitation_too_soon, e revoke_invitation recusa um que foi aceite primeiro com 409 invitation_accepted.

Códigos de verificação

add, update, remove, grant_address e revoke_address pedem um código de verificação a um token de acesso OAuth antes de alterarem o que quer que seja, e resend_invitation e revoke_invitation não. A chamada lança um OpenEmailApiError cujo is_step_up_required é True: peça um código com security.begin_step_up(), verifique o que a pessoa lhe der com security.verify_step_up({'code': ...}) e depois faça a chamada de novo. Uma verificação é válida durante 60 minutos, e a uma chave de API nunca é pedido.

Referência