Papéis, permissões e need-to-know
Introdução
O Sutram controla o acesso em dois níveis complementares:
- Papéis (ou funções) do projeto — o que cada pessoa pode fazer no projeto como um todo (navegar, criar, configurar).
- Need-to-know — quem enxerga o quê em conteúdo governado, onde a visibilidade depende do papel na classe e do estado do documento.
Entender os dois evita surpresas — desde "por que não consigo publicar?" até "por que não vejo este documento?".
Os quatro papéis do projeto
| Papel | Em uma frase |
|---|---|
| Proprietário | Controle total, incluindo o que é sensível (papéis, log de acesso, configurações). |
| Administrador | Gestão do dia a dia delegada pelo proprietário (membros e seus papéis básicos, schema, governança). Disponível no plano Max. |
| Membro | Cria e edita conteúdo. |
| Visualizador | Lê o conteúdo e participa de comentários e chat, mas não edita. |
O papel Administrador só pode ser atribuído em projetos no plano Max. Nos demais planos, os papéis disponíveis são Proprietário, Membro e Visualizador.
O que cada papel pode fazer
| Ação | Proprietário | Administrador | Membro | Visualizador |
|---|---|---|---|---|
| Navegar, buscar, ler e baixar conteúdo | Sim | Sim | Sim | Sim |
| Comentar e usar o chat do projeto | Sim | Sim | Sim | Sim |
| Criar/editar conteúdo, pastas e uploads; mover itens | Sim | Sim | Sim | Não |
| Versionar arquivos (checkout, checkin, publicar, criar versão) | Sim | Sim | Sim | Não |
| Forçar liberação de bloqueio de outro usuário | Sim | Sim | Não | Não |
| Criar e editar registros (records) | Sim | Sim | Sim | Não |
| Definir categorias e definições de metadados (schema) | Sim | Sim | Não | Não |
| Graduar classes e editar ciclos de vida (governança, plano Max) | Sim | Sim | Não | Não |
| Convidar e gerenciar membros | Sim | Sim | Não | Não |
| Alterar o papel de um membro | Sim | Sim* | Não | Não |
| Designar alguém como Administrador | Sim | Não | Não | Não |
| Ver o log de atividade (auditoria de escrita) | Sim | Sim | Não | Não |
| Ver o log de acesso (auditoria de leitura) | Sim | Sim | Não | Não |
* O administrador altera papéis apenas entre membro e visualizador. Ele não promove ninguém a administrador, nem mexe no papel de outro administrador ou do proprietário — essas mudanças ficam com o proprietário. O papel de proprietário não é atribuível: ele só muda por transferência de propriedade do projeto.
Para o passo a passo de convidar pessoas e atribuir papéis, veja Projetos e Membros.
Os princípios por trás da tabela
Em vez de decorar a tabela, guarde a lógica:
- Ler é aberto a todo participante — qualquer membro ativo, inclusive o visualizador, navega, busca e baixa o conteúdo comum.
- Escrever conteúdo exige um papel de edição — criar, editar, mover e versionar são de proprietário, administrador e membro.
- Configurar o projeto é de proprietário e administrador — schema de records, governança e gestão de membros.
- O topo da cadeia é só do proprietário — fazer backup do projeto, transferir a propriedade, excluir o projeto e convidar um administrador ficam com quem tem a palavra final.
- Auditoria é de quem administra — os dois logs, o de atividade (quem escreveu o quê) e o de acesso (quem leu o quê), estão abertos a proprietário e administrador.
- Participar é exceção à regra de escrita — comentar e conversar no chat são considerados read-adjacent: ficam abertos inclusive ao visualizador, porque feedback não é privilégio de edição de conteúdo.
Papéis do projeto × papéis de classe
Atenção para não confundir dois tipos de "papel":
- Papéis (ou funções) do projeto (proprietário, administrador, membro, visualizador) — são gerais e valem para todo o projeto.
- Papéis de classe (ex.: autor, revisor, aprovador) — existem dentro de uma Classe de Documento e definem quem age em cada etapa do fluxo de governança.
Uma mesma pessoa pode ser "membro" do projeto e "aprovador" numa classe específica. Veja Classes de Documentos e Governança.
Need-to-know: visibilidade por necessidade
Para o conteúdo comum, a regra é simples: se você participa do projeto, você o vê. A governança acrescenta uma camada de confidencialidade por necessidade (need-to-know), em dois graus:
- Por classe — no espaço de Conteúdo Governado, proprietário e administrador veem todas as Classes de Documento; membros e visualizadores veem apenas as classes onde possuem um papel.
- Por estado — dentro de uma classe, a matriz papel × estado define, para cada estado do ciclo de vida, quem pode ler e quem pode escrever. Um par (estado, papel) ausente significa sem acesso.
Na prática, isso permite que um documento em elaboração possa ficar invisível para quem só deveria vê-lo depois de aprovado — a confidencialidade acompanha o estágio do documento.
Acesso remoto (MCP) e papéis
O acesso via MCP Server respeita exatamente as mesmas permissões:
- Visualizadores conectam, mas com uma superfície somente-leitura — as ferramentas de escrita de conteúdo ficam ocultas e são negadas; comentários e chat permanecem disponíveis.
- Escrever conteúdo, versionar, gerir schema e governança seguem os mesmos papéis descritos acima.
Veja Conectando o Sutram ao Claude e o Guia do Sutram MCP Server.
Perguntas Frequentes
P: Por que não consigo adicionar um Administrador?
R: O papel Administrador só pode ser atribuído em projetos no plano Max. Em outros planos, use Membro ou Visualizador.
P: Um Visualizador pode comentar?
R: Sim. Comentar e usar o chat são ações de participação, abertas a qualquer participante ativo — inclusive visualizadores. O que o visualizador não pode é criar ou editar conteúdo.
P: Quem pode mudar o papel de outra pessoa?
R: Proprietários e administradores podem convidar participantes de um projeto e alterar seus papéis. Somente o Proprietário pode designar um participante como Administrador — o administrador só move pessoas entre membro e visualizador, e não altera o papel de outro administrador. O papel do Proprietário só muda se a propriedade do projeto for transferida.
P: Qual a diferença entre "papel do projeto" e "papel de classe de documento"?
R: O papel do projeto vale para tudo (proprietário, administrador, membro, visualizador). O papel de classe (autor, revisor, aprovador…) existe dentro de uma Classe de Documento e define quem age em cada etapa do fluxo de governança.
P: Por que não acho um documento que sei que existe (ou deveria existir)?
R: Provavelmente é conteúdo governado sob need-to-know: você não tem papel naquela classe, ou o documento está num estado cujo acesso de leitura não inclui o seu papel.
Versão do Documento: 1.0 Última Atualização: Julho de 2026 Autor: Equipe de Desenvolvimento Sutram