Usuarios de la app
Las cuentas de quien USA la aplicación construida — crear, activar y desactivar, actuar en lote — y los roles que deciden lo que cada uno ve y puede hacer.
Hay dos poblaciones en Keplin, y nunca se mezclan:
| Quién | Dónde entra | Dónde se gestiona |
|---|---|---|
| Quien construye | En la plataforma — ve la lista de apps, diseña pantallas, edita el modelo. | En Usuarios, en la zona de administración de la plataforma. |
| Quien usa | En la aplicación construida, por su dirección. Ni sabe que Keplin existe. | En Ajustes de la app → Usuarios de la app. |
Esta página trata de la segunda. El aviso en la parte superior de la sección no podría ser más claro: «Estos usuarios son de la app construida — hacen login en la app en runtime y no tienen ningún acceso a la plataforma KEPLIN.»
La lista de cuentas
Abre Ajustes de la app (el engranaje en la parte superior del árbol) y, en el grupo Usuarios, la sección Usuarios de la app.

Cada fila trae el Usuario (username, nombre y correo), los Roles y el Último acceso — «nunca entró» cuando nunca hubo login. Una cuenta desactivada aparece marcada como Desactivado.
Sobre la lista hay tres herramientas de búsqueda:
- la búsqueda «Buscar por nombre, usuario o correo…»;
- el filtro por role (Todos los roles, o Sin ningún role);
- el filtro por estado (Todos los estados).
El aviso que resuelve la mitad de los problemas
Cuando hay cuentas sin ningún role, aparece un aviso ámbar: «{n} usuario(s) sin ningún role — no ven datos ni pantallas. Haz clic para verlos.»

Es clicable, y filtra al momento esas cuentas. Vale la pena saber esto de memoria: la causa número uno de «entré en la app y está todo vacío» es una cuenta sin role. Sin role no hay permisos, y sin permisos no hay datos ni pantallas.
Crear y editar cuentas
Nuevo usuario abre la ficha — en página, nunca en modal.

| Campo | Notas |
|---|---|
| Username | Obligatorio. «Letras, números, punto, guion, _ y @.» Es lo que la persona escribe en la pantalla de entrada. |
| Nombre | Opcional. Lo que aparece en las listas y en las asignaciones de tareas. |
| Correo | Opcional, pero necesario para recuperar la contraseña y para recibir informes programados. |
| Contraseña | En la creación es la contraseña inicial — «el usuario puede cambiarla en la app». En la edición, «solo rellénala para definir una contraseña nueva». |
| Activo | Desactivado, la cuenta existe pero «no puede entrar en la app». |
| Roles | Los roles de esta cuenta. Una cuenta nueva trae premarcados los que estén definidos como Dado por defecto. |
Guarda con Guardar. Para editar una cuenta existente, el menú ⋮ de la fila → Editar; para borrarla, Borrar — irreversible, y el usuario deja de poder entrar.
Consejo
Desactivar es casi siempre mejor que borrar. La cuenta desactivada no entra, pero el historial sigue teniendo sentido: las tareas que decidió, los registros que creó, las notificaciones que recibió.
Cambiar la contraseña de una cuenta (aquí, o con la recuperación por correo) cierra las sesiones que tenía abiertas, en la web y en KeplinGo: quien la usaba tiene que entrar otra vez.
En lote
Selecciona varias filas con las casillas de la izquierda y aparece la barra de acciones: Dar role, Quitar role, Activar, Desactivar. Dar el mismo role a doce personas es una operación, no doce fichas.
Nota
Los permisos no se editan en la cuenta — se editan siempre en los roles. Una excepción puesta en una persona es una excepción que nadie vuelve a encontrar.
Los roles
La sección Permisos define lo que cada role puede hacer. «Cada role dice lo que se puede hacer. Los permisos se suman: quien tiene dos roles se queda con lo mejor de los dos.»

La lista muestra cada role con la descripción, cuántos Usuarios lo tienen y cuántas Reglas tiene. Las insignias dicen el resto: por defecto (dado a quien se registre o sea creado de nuevo) y acceso total.
Nuevo role crea uno; el menú ⋮ de una fila tiene Editar y Eliminar. Eliminar avisa cuántas personas se quedan sin él — «y quien se quede sin ningún role deja de ver datos».
Un role se abre con cinco pestañas.
General
| Campo | Qué hace |
|---|---|
| Nombre / Descripción | Identificación. La descripción aparece en la lista y en la ficha de los usuarios. |
| Acceso total | «Todo, sin excepciones — y sigue siendo correcto cuando la app crezca.» |
| Dado por defecto | «Asignado a quien se registre o sea creado de nuevo.» |
Sobre el Acceso total: «no hay reglas que listar: una API o una pantalla creadas mañana ya le pertenecen. Es lo que se quiere en un administrador — y es lo opuesto de lo que se quiere en todos los demás.»
Datos — lo que cada uno llega a ver
La pestaña que más cuenta. Una fila por API de tabla, con cuatro marcas — Ver, Crear, Modificar, Borrar — y el Ámbito de los registros.
| Ámbito | Significa |
|---|---|
| Todos los registros | Sin restricción de filas. |
| Solo los míos | Solo los registros cuyo «Campo que dice de quién es» sea el usuario con sesión. |
| Con condición… | Solo los registros que cumplan un filtro — con valores fijos o venidos de la sesión de quien está usando la app. |
Y la frase que decide la arquitectura de seguridad de una app entera:
«El ámbito se aplica en el servidor, en todas las lecturas y escrituras — en las pantallas, en el código, en los informes y en los workflows. Sin ninguna regla, este role no ve nada de esta API.»
Es decir: un informe no se salta los permisos, un workflow no se salta los permisos, un evento de pantalla no se salta los permisos. Todos pasan por el mismo filtro, en el servidor.
En las escrituras, el ámbito vale para el registro que cambia y para los valores que lleva. Cambiar o eliminar solo ocurre en registros al alcance del rol; crear o cambiar con valores que quedarían fuera (otro dueño, otra región) se rechaza con el motivo. Y en las relaciones también: si el rol tiene reglas para la API de una entidad, las filas de esa entidad leídas a través de otra (los pedidos de un cliente) cumplen esas reglas.
Pantallas
Para cada pantalla y cada dispositivo — Web, Tablet, Móvil — un nivel de acceso:

| Nivel | Qué hace |
|---|---|
| Oculto | «No aparece en los menús, y la ruta escrita a mano se rechaza.» |
| Ver (solo lectura) | «Se abre en solo lectura — los campos y botones que graban quedan desactivados.» |
| Editar | «Se abre y funciona.» |
Los atajos ver todos / ocultar todos, en la cabecera de cada columna, rellenan el dispositivo entero de una vez.
Atención
«El "ver" es una ayuda visual; quien frena la escritura de verdad son los permisos de Datos, en el servidor.» Una pantalla en solo lectura evita errores; no detiene a nadie decidido. La puerta que cierra de verdad es la de Datos.
Una pantalla oculta en todos los dispositivos ni siquiera llega al navegador de quien no puede abrirla: el servidor rechaza el documento.
Menús
Al contrario que las pantallas, un menú es visible por defecto — «la puerta es la pantalla, y esa ya está cerrada». Aquí se esconde el resto: un grupo entero del menú, la campana de las notificaciones, una entrada concreta, por dispositivo. Desmarcar un grupo se lleva a los hijos con él.
Acciones
Las acciones son «los verbos que solo existen en esta app: aprobar, cerrar,
exportar». Se declaran una vez, en el panel Acciones de la lista de
roles — una Clave (aprovar-oportunidade) y un Nombre («Aprobar
oportunidad»), botón Nueva acción — y cada role marca las que da.

Se usan en dos sitios:
- en las propiedades de cualquier widget, en el campo Acceso, para que el widget solo aparezca a quien tiene la acción;
- en código TypeScript:
keplin.session.can("aprovar-oportunidade").
Una acción que nadie da aparece marcada como «ningún role la da» — señal de que o falta asignarla, o ya no sirve para nada.
Todo se guarda de una vez, en Guardar.
Cómo se junta esto en runtime
Cuando una persona entra en la app publicada:
- Se autentica con la cuenta de la app.
- Sus roles se suman: se queda con lo mejor de cada uno.
- Los menús y las pantallas se filtran antes de que la página dibuje.
- Cada lectura y cada escritura pasan por el ámbito de datos, en el servidor — venga de las pantallas, de un informe, de un workflow o de un script.
La sesión de una cuenta dura 12 horas y se renueva mientras la persona trabaja, en la web y en KeplinGo: solo la inactividad prolongada la termina. Cuando termina, la pantalla dice que la sesión ha terminado y pide volver a entrar.
Preguntas frecuentes
Creé la cuenta, la persona entra, y no ve nada. Probablemente no tiene role. Mira el aviso ámbar en la lista de usuarios. Si tiene role, confirma en la pestaña Datos de ese role si hay reglas — «sin ninguna regla, este role no ve nada de esta API».
Quiero que cada comercial vea solo sus oportunidades. En la pestaña Datos, ámbito Solo los míos, con el Campo que dice de quién es apuntado al campo del responsable. Funciona en todas partes, incluidos los informes.
¿Un usuario de la app puede entrar en la plataforma? No. Son cuentas de mundos distintos, guardadas por separado. Un usuario de la app no tiene ningún acceso a la plataforma, y una cuenta de la plataforma no entra en la app construida sin tener ahí cuenta propia.
¿Las cuentas viajan cuando exporto la app? Por defecto no: «viaja la aplicación, con los roles y los permisos, no quien la usa». Solo la exportación con secretos, protegida por passphrase lleva también las cuentas. Ver Importar y exportar apps.

