KEPLIN Docs

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.

La lista de usuarios de la app Gestión de Clientes: los roles de cada cuenta y el último acceso.
La lista de usuarios de la app Gestión de Clientes: los roles de cada cuenta y el último acceso.

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.»

El aviso de las cuentas sin role, pulsado
El aviso de las cuentas sin role, pulsado

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.

La ficha de un usuario de la app — username, nombre, correo, contraseña inicial, estado y roles.
La ficha de un usuario de la app — username, nombre, correo, contraseña inicial, estado y roles.

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 sección Permisos de la app: los roles, con los usuarios y las reglas de cada uno, y las acciones declaradas debajo.
La sección Permisos de la app: los roles, con los usuarios y las reglas de cada uno, y las acciones declaradas debajo.

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

La pestaña General de un role
La pestaña General de un role

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.

La pestaña Datos de un role
La pestaña Datos de un role

Á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:

La pestaña Pantallas de un role
La pestaña Pantallas de un role

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.

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.

La pestaña Acciones de un role
La pestaña Acciones de un role

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:

  1. Se autentica con la cuenta de la app.
  2. Sus roles se suman: se queda con lo mejor de cada uno.
  3. Los menús y las pantallas se filtran antes de que la página dibuje.
  4. 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.