70 lines
3.3 KiB
Markdown
70 lines
3.3 KiB
Markdown
# GLM Hub — LED de acceso + jefe inmediato
|
|
|
|
## Qué cambia
|
|
|
|
Esta versión agrega dos mejoras sin cambiar el modelo actual de autenticación del Hub:
|
|
|
|
1. Cada aplicación publicada muestra el estado **Con acceso / Sin acceso** del usuario conectado.
|
|
2. Las solicitudes de acceso se envían a **Isaac Aracena, José Leopoldo Gómez, Máximo Gómez y al jefe inmediato del solicitante**, cuando `empleados_glm.supervisor_email` está disponible.
|
|
|
|
La primera decisión registrada sigue siendo definitiva para todos los aprobadores.
|
|
|
|
## Fuentes de acceso utilizadas
|
|
|
|
El Hub no replica los permisos de las aplicaciones restringidas: consulta su fuente real en Supabase.
|
|
|
|
- **CDC Project Management** → `tablero_cdc_allowed_users` (`email`, `is_active`).
|
|
- **Portal de Verificación de Nóminas** → `cruce_cuentas_usuarios_autorizados` (`email`).
|
|
- **Seguimiento de Impuestos GLM** → `tax_calendar_access` (`email`, `active`).
|
|
- **BambooHR, CDC Brief, los 5 Cruces de Seguridad Social, Validación de IR - Nicaragua y GLM ID Card Generator** → acceso general para usuarios autenticados `@gomezleemarketing.com`.
|
|
- Cualquier aplicación futura que no esté clasificada se muestra por seguridad como **Sin acceso** hasta agregar su regla al RPC.
|
|
|
|
El estado se vuelve a comprobar al iniciar sesión, cada 60 segundos y cuando el usuario vuelve a enfocar la pestaña del Hub.
|
|
|
|
## Orden de implementación
|
|
|
|
### 1. Supabase
|
|
|
|
Ejecutar completo:
|
|
|
|
`SUPABASE-GLM-HUB-LED-ACCESO-JEFE-INMEDIATO.sql`
|
|
|
|
Este script:
|
|
|
|
- elimina la restricción que limitaba los aprobadores a tres correos exactos;
|
|
- conserva a los tres aprobadores base;
|
|
- obtiene el jefe desde `empleados_glm.work_email → supervisor_email`;
|
|
- evita duplicados;
|
|
- no rompe la solicitud si el jefe no está disponible;
|
|
- crea el RPC `glm_hub_get_my_app_access()` para el LED.
|
|
|
|
### 2. n8n
|
|
|
|
Actualizar el workflow **GLM Hub - Solicitudes de acceso y aprobación** con:
|
|
|
|
`n8n/GLM-Hub-Solicitudes-Acceso-Aprobacion.json`
|
|
|
|
No se modificó el workflow de Gemini. Tampoco se cambió la forma actual en que el workflow usa las credenciales/keys de Supabase, por solicitud expresa.
|
|
|
|
### 3. Frontend
|
|
|
|
Publicar el contenido nuevo de `dist/` en el mismo subdominio del GLM Hub.
|
|
|
|
## Prueba recomendada
|
|
|
|
1. Iniciar sesión con un usuario GLM que no sea administrador.
|
|
2. Confirmar que cada app muestre **Con acceso** o **Sin acceso**.
|
|
3. Verificar un usuario presente y otro ausente en cada una de las tres tablas restringidas.
|
|
4. Enviar una solicitud de acceso.
|
|
5. En la ejecución de n8n, revisar `Emitir enlaces de aprobación`: debe devolver 3 aprobadores base y, cuando exista, un cuarto aprobador correspondiente al `supervisor_email`.
|
|
6. Confirmar que todos reciban su correo.
|
|
7. Aprobar con uno de ellos y comprobar que un segundo intento muestre que la solicitud ya fue atendida.
|
|
8. Agregar/eliminar al usuario en la tabla real de una app restringida y volver al Hub; al recuperar el foco (o como máximo en 60 segundos) el LED debe actualizarse.
|
|
|
|
## Comportamiento de seguridad
|
|
|
|
- Un usuario sin registro en `glm_hub_authorized_users` sigue entrando al Hub si pertenece a `@gomezleemarketing.com`.
|
|
- `glm_hub_authorized_users` continúa usándose para administradores y bloqueos excepcionales.
|
|
- El LED es informativo: no sustituye la protección interna de cada aplicación.
|
|
- Las aplicaciones no clasificadas no se marcan automáticamente como autorizadas.
|