Utilizadores da app
As contas de quem USA a aplicação construída — criar, activar e desactivar, agir em lote — e os papéis que decidem o que cada um vê e pode fazer.
Há duas populações no Keplin, e nunca se misturam:
| Quem | Onde entra | Onde é gerido |
|---|---|---|
| Quem constrói | Na plataforma — vê a lista de apps, desenha ecrãs, edita o modelo. | Em Utilizadores, na zona de administração da plataforma. |
| Quem usa | Na aplicação construída, pelo endereço dela. Nem sabe que o Keplin existe. | Em Definições da app → Utilizadores da app. |
Esta página é sobre a segunda. O aviso no topo da secção não podia ser mais claro: "Estes utilizadores são da app construída — fazem login na app em runtime e não têm nenhum acesso à plataforma KEPLIN."
A lista de contas
Abre Definições da app (a engrenagem no topo da árvore) e, no grupo Utilizadores, a secção Utilizadores da app.
Cada linha traz o Utilizador (username, nome e email), os Roles e o Último acesso — "nunca entrou" quando nunca houve login. Uma conta desactivada aparece marcada como Desactivado.
Por cima da lista há três ferramentas de busca:
- a pesquisa "Procurar por nome, utilizador ou email…";
- o filtro por role (Todos os roles, ou Sem role nenhum);
- o filtro por estado (Todos os estados).
O aviso que resolve metade dos problemas
Quando há contas sem papel nenhum, aparece um aviso âmbar: "{n} utilizador(es) sem role nenhum — não vêem dados nem ecrãs. Clica para os ver."
É clicável, e filtra logo essas contas. Vale a pena saber isto de cor: a causa número um de "entrei na app e está tudo vazio" é uma conta sem role. Sem papel não há permissões, e sem permissões não há dados nem ecrãs.
Criar e editar contas
Novo utilizador abre a ficha — em página, nunca em modal.
| Campo | Notas |
|---|---|
| Username | Obrigatório. "Letras, números, ponto, hífen, _ e @." É o que a pessoa escreve no ecrã de entrada. |
| Nome | Opcional. O que aparece nas listas e nas atribuições de tarefas. |
| Opcional, mas necessário para recuperar a password e para receber relatórios agendados. | |
| Password | Na criação é a password inicial — "o utilizador pode alterá-la na app". Na edição, "só preenche para definir uma password nova". |
| Activo | Desligado, a conta existe mas "não consegue entrar na app". |
| Roles | Os papéis desta conta. Uma conta nova traz pré-marcados os que estiverem definidos como Dado por omissão. |
Grava com Gravar. Para editar uma conta existente, o menu ⋮ da linha → Editar; para a apagar, Apagar — irreversível, e o utilizador deixa de conseguir entrar.
Dica
Desactivar é quase sempre melhor do que apagar. A conta desactivada não entra, mas o histórico continua a fazer sentido: as tarefas que ela decidiu, os registos que criou, as notificações que recebeu.
Em lote
Selecciona várias linhas com as caixas à esquerda e a barra de acções aparece: Dar role, Tirar role, Activar, Desactivar. Dar o mesmo papel a doze pessoas é uma operação, não doze fichas.
Nota
As permissões não se editam na conta — editam-se sempre nos roles. Uma excepção posta numa pessoa é uma excepção que ninguém volta a encontrar.
Os papéis
A secção Permissões define o que cada role pode fazer. "Cada role diz o que se pode fazer. As permissões somam-se: quem tem dois roles fica com o melhor dos dois."
A lista mostra cada role com a descrição, quantos Utilizadores o têm e quantas Regras tem. Os crachás dizem o resto: omissão (dado a quem se registar ou for criado de novo) e acesso total.
Novo role cria um; o menu ⋮ de uma linha tem Editar e Eliminar. Eliminar avisa quantas pessoas ficam sem ele — "e quem ficar sem role nenhum deixa de ver dados".
Um role abre com cinco separadores.
Geral
| Campo | O que faz |
|---|---|
| Nome / Descrição | Identificação. A descrição aparece na lista e na ficha dos utilizadores. |
| Acesso total | "Tudo, sem excepções — e continua certo quando a app crescer." |
| Dado por omissão | "Atribuído a quem se registar ou for criado de novo." |
Sobre o Acesso total: "não há regras a listar: uma API ou um ecrã criados amanhã já lhe pertencem. É o que se quer num administrador — e é o oposto do que se quer em todos os outros."
Dados — o que cada um chega a ver
O separador que conta mais. Uma linha por API de tabela, com quatro vistos — Ver, Criar, Alterar, Apagar — e o Âmbito dos registos.
| Âmbito | Significa |
|---|---|
| Todos os registos | Sem restrição de linhas. |
| Só os meus | Só os registos cujo "Campo que diz de quem é" for o utilizador com sessão. |
| Com condição… | Só os registos que cumprirem um filtro — com valores fixos ou vindos da sessão de quem está a usar a app. |
E a frase que decide a arquitectura de segurança de uma app inteira:
"O âmbito é aplicado no servidor, em todas as leituras e escritas — nos ecrãs, no código, nos relatórios e nos workflows. Sem regra nenhuma, este role não vê nada desta API."
Ou seja: um relatório não fura as permissões, um workflow não fura as permissões, um evento de ecrã não fura as permissões. Todos passam pelo mesmo filtro, no servidor.
Ecrãs
Para cada ecrã e cada dispositivo — Web, Tablet, Telemóvel — um nível de acesso:
| Nível | O que faz |
|---|---|
| Escondido | "Não aparece nos menus, e a rota escrita à mão é recusada." |
| Ver (só leitura) | "Abre em só leitura — campos e botões que gravam ficam desactivados." |
| Editar | "Abre e funciona." |
Os atalhos ver todos / esconder todos, no cabeçalho de cada coluna, preenchem o dispositivo inteiro de uma vez.
Atenção
"O «ver» é uma ajuda visual; quem trava a escrita a sério são as permissões de Dados, no servidor." Um ecrã em só leitura evita erros; não impede ninguém determinado. A porta que fecha mesmo é a de Dados.
Menus
Ao contrário dos ecrãs, um menu é visível por omissão — "a porta é o ecrã, e essa já está fechada". Aqui esconde-se o resto: um grupo inteiro do menu, o sino das notificações, uma entrada específica, por dispositivo. Desmarcar um grupo leva os filhos com ele.
Acções
As acções são "os verbos que só existem nesta app: aprovar, fechar,
exportar". Declaram-se uma vez, no painel Acções da lista de roles — uma
Chave (aprovar-oportunidade) e um Nome ("Aprovar oportunidade"),
botão Nova acção — e cada role marca as que dá.
Usam-se em dois sítios:
- nas propriedades de qualquer widget, no campo Acesso, para o widget só aparecer a quem tem a acção;
- em código TypeScript:
keplin.session.can("aprovar-oportunidade").
Uma acção que ninguém dá aparece marcada como "nenhum role a dá" — sinal de que ou falta atribuí-la, ou já não serve para nada.
Tudo se grava de uma vez, em Gravar.
Como isto se junta em runtime
Quando uma pessoa entra na app publicada:
- Autentica-se com a conta da app (ou pelo fornecedor de identidade da organização, se a app estiver em OAuth).
- Os roles dela somam-se: fica com o melhor de cada.
- Os menus e os ecrãs são filtrados antes de a página desenhar.
- Cada leitura e cada escrita passam pelo âmbito de dados, no servidor — venha dos ecrãs, de um relatório, de um workflow ou de um script.
Perguntas frequentes
Criei a conta, a pessoa entra, e não vê nada. Provavelmente não tem role. Vê o aviso âmbar na lista de utilizadores. Se tem role, confirma no separador Dados desse role se há regras — "sem regra nenhuma, este role não vê nada desta API".
Quero que cada comercial veja só as oportunidades dele. No separador Dados, âmbito Só os meus, com o Campo que diz de quem é apontado ao campo do responsável. Funciona em todo o lado, incluindo nos relatórios.
Um utilizador da app consegue entrar na plataforma? Não. São contas de mundos diferentes, guardadas separadamente. Um utilizador da app não tem nenhum acesso à plataforma, e uma conta da plataforma não entra na app construída sem lá ter conta própria.
As contas viajam quando exporto a app? Por omissão não: "viaja a aplicação, com os roles e as permissões, não quem a usa". Só a exportação com segredos, protegida por passphrase leva também as contas. Ver Importar e exportar apps.