Permissions

Visão geral

O OutDo controla o acesso a dois níveis independentes:

1. Workspace role — uma role (Owner, Admin, Dev, User, ou View) que define a base do que um utilizador pode fazer num workspace, ou em toda uma organização.
2. Permission overlay — afinação opcional sobre a role: que partes do workspace um utilizador pode ver (visibilidade) e que operações pode realizar sobre os dados de uma feature (adicionar / editar / eliminar).

Versões anteriores do OutDo atribuíam uma única role — Admin, Editor, Viewer, ou Restricted — diretamente a cada objeto (um workspace, um módulo, uma feature…). Esse modelo deixou de existir. Já não há role por objeto: o acesso é sempre workspace role + overlay.

Ambos os níveis são configurados na secção Permissions do Painel de administração. Só para chegar a essa secção já é preciso ter a role Admin (ou Owner, ou platform superadmin) no workspace — as contas Dev e User não a veem.

Workspace roles

A role é a base. É atribuída por workspace (ou a nível de toda a organização, herdada por todos os workspaces da organização que não tenham uma role mais específica).

Role	O que concede
Owner	Automática — o utilizador que criou a organização. Acesso total a tudo nela; não é atribuível através da interface. Transferível através de Transferir ownership no separador Funções.
Admin	Controlo total do workspace: gerir utilizadores, roles e permissões, configurar tudo, todas as operações de dados sem restrições. Os overlays não se aplicam ao Admin.
Dev	Configura o workspace — features, vistas, módulos, rails — e realiza todas as operações de dados, mas não tem acesso à gestão de utilizadores/roles/permissões do painel de administração. Os overlays não se aplicam ao Dev.
User	Operador normal. Pode adicionar/editar/eliminar por predefinição; um permission overlay pode restringir features específicas.
View	Só de leitura. Recusa sempre operações de escrita, independentemente de qualquer overlay.

Kiosk é um conceito à parte — uma flag na conta de utilizador, não uma workspace role. Um utilizador kiosk normalmente também tem uma role User no workspace onde está fixado. Consulta Organizations & Workspaces.

Roles são atribuídas no separador Funções (ver abaixo), não em Visibilidade/Operações.

Overlays de permissões

Os overlays só afetam a role User — Admin/Dev/Owner ignoram-nos por completo, e o View recusa sempre a escrita, seja o que for que o overlay diga. Um overlay só pode restringir um User, nunca conceder mais do que a role já permite.

Um overlay tem duas partes independentes:

Parte	Aplica-se a	Controla
Visibilidade	Workspace, Module, Rail, View	Se o objeto é mostrado ou não (toggle on/off)
Operações	Feature	Se é permitido adicionar / editar / eliminar nos registos dessa feature

A Visibilidade é hierárquica: desligar um Module também esconde os seus Rails e Views (e voltar a ligá-lo não os restaura — tens de reativar cada nível explicitamente). As Operações são por feature, independentes da árvore de visibilidade.

Cada feature também tem um quarto switch, Visualizar, ao lado das três operações. É apenas informativo e não editável — aparece ativo automaticamente quando qualquer operação de escrita está ativa, mas não controla a leitura por si só. Quem controla mesmo a leitura é a Visibilidade.

Gerir permissões no Painel de administração

Abre o Painel de administração do workspace e vai a Permissions. A barra lateral lista três grupos — Templates, Grupos, Utilizadores — todos pesquisáveis e expansíveis. Clica numa entrada para a selecionar; o corpo muda da vista de cartões para um conjunto de separadores dessa entidade.

Os utilizadores têm quatro separadores: Funções, Visibilidade, Operações, Auditoria. Templates e Grupos têm dois: Visibilidade, Operações — estás a editar a configuração própria guardada do template ou do grupo, em vez da de um utilizador específico.

Funções (só utilizadores)

Mostra a role do utilizador selecionado: uma linha Toda a organização (a nível de toda a organização, herdada por todos os workspaces sem uma linha mais específica) mais uma linha por workspace da organização. Cada linha tem um dropdown: Sem role, View, User, Dev, Admin. Uma escolha específica de um workspace substitui a de toda a organização apenas para esse workspace.

O owner da organização aparece como um chip fixo Owner em vez de um dropdown, com uma ação Transferir ownership para quem possa gerir roles.

Visibilidade

Para um Template ou Grupo, isto é uma árvore — Workspace → Module → Rail → View — com um toggle em cada nó. Desligar um nó tem efeito em cascata: os seus filhos também perdem visibilidade.

Exemplo: para esconder um módulo de um grupo, seleciona o grupo em Grupos, abre Visibilidade, e desliga o toggle desse módulo. Todos os rails e vistas por baixo dele desaparecem também, para quem quer que o grupo se aplique.

Para um User individual, este separador mostra atualmente uma mensagem em vez da árvore — a edição de visibilidade por utilizador ainda não está disponível. O próprio acesso ao workspace é controlado a partir de Funções; a visibilidade mais fina (módulo/rail/vista) é configurada num Template, e depois aplicada ao utilizador através de Aplicar (ver abaixo).

Operações

Uma lista pesquisável das features do workspace. Cada linha tem quatro switches — Adicionar, Editar, Apagar, Visualizar. Os três primeiros correspondem a add/edit/delete; o Visualizar é apenas um indicador só de leitura (não editável) que fica ativo automaticamente quando alguma operação de escrita está ativa — ver acima. Os cabeçalhos de coluna têm um switch que aplica em massa a todas as features visíveis de uma vez (exceto o Visualizar, que também é só indicador).

Este separador funciona da mesma forma para Users, Templates e Grupos — para um utilizador edita diretamente o overlay desse utilizador; para um template/grupo edita a configuração reutilizável.

Exemplo: para remover o acesso de eliminação a uma feature para um utilizador, seleciona o utilizador, abre Operações, procura a feature, e desliga o Apagar. As outras operações mantêm-se como estavam.

Auditoria (só utilizadores)

Um registo de alterações de role da organização, limitado ao workspace: concessões, revogações e alterações, cada uma com quem fez a alteração, quando, e (para linhas a nível de toda a organização) um badge org-wide. Paginado — Carregar mais carrega entradas mais antigas.

Templates de permissões

Um Permission Template junta uma role com um overlay para poderes aplicar os dois em conjunto, em vez de configurar um utilizador do zero. Cada organização já vem com quatro templates incorporados:

Template	Role	Para que serve
Admin	Admin	Gestor do workspace — tudo sem restrições.
Dev	Dev	Configura features/vistas/módulos/rails, acesso total a dados, sem gestão de utilizadores/roles/permissões.
Member	User	Operador normal, adicionar/editar/eliminar permitido por predefinição; restringe features específicas depois via Operações.
Viewer	View	Só de leitura — auditores, stakeholders.

Os templates incorporados vêm com um overlay vazio (só role). Cria um template personalizado a partir de Adicionar template: começa em branco ou escolhe um dos incorporados no dropdown Predefinição para pré-preencher a sua role e overlay, e depois renomeia e ajusta. Depois de guardado, os separadores Visibilidade e Operações de um template personalizado comportam-se como os de um grupo, não como os de um utilizador: Visibilidade mostra a árvore real (só Templates e Grupos a têm — Users têm o placeholder descrito acima), enquanto Operações reutiliza os mesmos switches por feature para os três tipos de entidade.

Usa Aplicar para aplicar um template em massa a utilizadores — é a ação que aparece ao passar o rato sobre o cartão do template na grelha de Templates (tooltip "Aplicar a utilizadores"), não um item do menu de contexto. Escolhe um âmbito — um workspace específico ou toda a organização — e seleciona um ou mais membros da organização. Aplicar é idempotente — voltar a aplicar a um utilizador que já corresponde à role e ao overlay do template não tem qualquer efeito.

Grupos de permissões

Um Permission Group é uma configuração com nome ligada a um template — útil para manter uma cópia editável e identificada de um perfil de permissões (por exemplo, "Sales Team", ajustado a partir do template Member). Tal como os templates, os separadores Visibilidade e Operações de um grupo editam diretamente a sua própria configuração guardada, com a árvore de visibilidade real.

Os grupos não têm ação Aplicar nem lista de membros — não há forma de atribuir um grupo diretamente a um conjunto de utilizadores. Um grupo é apenas uma configuração guardada e identificada. Para efetivamente conceder as suas definições a utilizadores, aplica o template a que está ligado (ou um template que tenhas ajustado para corresponder) através da ação Aplicar desse template.

Dicas

• Os overlays nunca concedem mais do que a role já permite — se um User não vir um switch de operação ativo onde esperavas, confirma primeiro a role (Dev/Admin/Owner ignoram overlays; o View recusa sempre a escrita).
• Para alterar o que um grupo de pessoas pode aceder de uma vez, edita um Template e usa Aplicar em vez de repetir a mesma alteração por utilizador.
• Os toggles de visibilidade propagam-se em cascata para baixo quando os desligas, mas não quando os voltas a ligar — reativar um módulo não restaura rails/vistas que tinhas escondido individualmente antes.
• Para um utilizador individual, edita a visibilidade no template que vais aplicar-lhe, não diretamente no utilizador — a árvore por utilizador ainda não está disponível.