Base de conhecimento

Papéis e níveis de permissão

Um papel diz o que alguém pode fazer; uma concessão de endereço diz sobre o que o pode fazer.

Detalhes

Duas concessões por pessoa, e ambas têm de concordar antes de algo acontecer. O PAPEL, definido em Definições → Membros, diz o que podem FAZER no espaço de trabalho: ler correio, enviá-lo, editar modelos, adicionar um domínio, cunhar uma chave de API. A CONCESSÃO de endereço, definida no controlo Partilhar da linha do endereço, diz sobre que ENDEREÇOS o podem fazer, em apenas leitura ou leitura e envio. Quem tenha um papel com envio e nenhum endereço não pode enviar a partir de nada; quem tenha todos os endereços do espaço de trabalho sob uma concessão de apenas leitura também não pode enviar a partir de nenhum.
Existem seis papéis sem que ninguém os crie, e todos os espaços de trabalho têm os mesmos seis, por isso “Admin” significa aqui o mesmo que significa na documentação e na API. Owner, Admin, Member e Viewer são uma escada: cada um tem tudo o que o seguinte tem, por isso despromover alguém estreita o que pode alcançar em vez de o trocar por uma fatia diferente. Developer e Billing não são degraus dessa escada. O Developer constrói integrações, tendo chaves de API, webhooks, modelos e envio sem ler nada do correio do espaço de trabalho, e o Billing vê o plano e as faturas, pode mudar o plano e os dados de pagamento neles, e lê as definições da caixa de correio sem poder escrever nenhuma. As permissões deles são editáveis: um espaço de trabalho que prefira que os seus membros não escrevam modelos desmarca-o, e a alteração chega no pedido seguinte de quem tenha EXPLICITAMENTE esse papel. Quem tenha o papel ainda implícito por uma concessão de endereço feita antes de os papéis existirem mantém os valores de origem até lhe ser atribuído um de forma expressa. Os nomes também são editáveis: um espaço de trabalho que funciona com Ops e Piquete renomeia-os e está a descrever-se a si próprio, que é o objetivo.
O Owner é a exceção em todas as direções: não é editável, nem eliminável, nem atribuível. Descreve a conta em que o espaço de trabalho está ancorado e detém todas as permissões, incluindo as adicionadas numa versão posterior, e é por isso que a sua lista é calculada em vez de guardada. Entregar o espaço de trabalho a outra pessoa é uma transferência e não uma mudança de papel, e não há aqui nada que faça uma.
Para além desses, um espaço de trabalho escreve os seus próprios, até 24 no total, marcando permissões na mesma matriz agrupada. Marcar implica: “editar modelos” guarda “ler modelos” ao lado, porque um papel que pode editar um modelo que não consegue abrir é uma caixa que alguém se esqueceu de marcar e não uma política que alguém queira. Eliminar um papel que pessoas ou chaves de API tenham pergunta para onde as mover e recusa em vez de adivinhar. Uma chave cujo papel desaparecesse ficaria sem teto nenhum, o que é mais amplo do que o papel que acabou de sair.
Uma chave de API pode ser emitida contra um papel, e o papel é um teto e não uma segunda concessão: o que a chave pode fazer são os seus próprios scopes intersetados com as permissões do papel, resolvidos em cada pedido. Uma chave criada com envio e limitada por Viewer não consegue enviar, e estreitar um papel revoga-o ao vivo sem que a chave tenha de ser rodada. O assistente está sujeito à mesma lista, e o servidor MCP constrói as ferramentas de um cliente a partir das permissões de quem chama, por isso o cliente de um viewer não tem ferramenta de envio nenhuma, e todas as ferramentas protegidas voltam a verificar à entrada, porque uma sessão pode mudar de caixa de correio depois de a lista ter sido construída.