Ir al contenido
Nicolás Amorosi

Unión Italiana de Iglesias Adventistas

Plataforma de RR. HH.

El personal y los pastores de la Unión reportan su trabajo cada mes, piden licencias y reintegros, y esperan que las personas correctas los aprueben. Lideré el equipo que construyó la plataforma para eso: primero una primera generación y después la reescritura que la reemplazó.

El problema

Dos tipos de personal con reglas distintas —empleados bajo convenio colectivo y pastores—, cada uno con su reporte mensual, más ausencias, gastos médicos, invitaciones de viaje y exportaciones para tesorería.

Cada solicitud tiene que subir por una jerarquía antes de valer, y a fin de mes tesorería y secretaría necesitan exportaciones que puedan usar sin volver a tipear nada.

Restricciones

  • Italiano por defecto, con español e inglés para un personal internacional.
  • Inicio de sesión con las cuentas Microsoft de la organización; emails a través de Microsoft Graph.
  • Un equipo de tres desarrolladores, con dos más rotando.
  • Reemplazar la primera generación, que también había arrancado yo.

Qué construí

La primera generación, Rapportopastori: un monorepo NestJS y Next.js con inicio de sesión único de Microsoft, reportes PDF generados con Puppeteer y deploys a AWS EC2 con GitHub Actions. Armé el monorepo y el inicio de sesión único.

Después PDOA, su reemplazo, sobre la misma arquitectura que Libretto: route handlers de Next.js delante de una API en NestJS 11 con Prisma y MySQL, sesiones JWT sin estado en cookies HttpOnly, login con Microsoft Entra ID, archivos en S3 y emails con Graph. Escribí el stack inicial, la autenticación y el inicio de sesión único, y guié al equipo en el resto.

Lo difícil

  1. Solicitud enviada

    Nivel 3

  2. Aprobador, nivel 2

    Foto guardada

  3. Aprobador, nivel 1

    Foto guardada

  4. Aprobación final

    Quien tenga el permiso de aprobación final

  5. Reporte completado

    Las ausencias aprobadas se vuelven entradas del reporte mensual

Se arma al enviar la solicitud, subiendo por la jerarquía. Cada paso guarda una foto de su aprobador, así una reorganización nunca reescribe aprobaciones pasadas.

Cadenas de aprobación desde la jerarquía

Cada rol tiene un nivel jerárquico. Cuando alguien envía una solicitud, la cadena se arma subiendo por sus responsables —quien está en el nivel 3 necesita aprobadores de nivel 2 y 1—, con protección contra ciclos y un paso final para quien tenga el permiso de aprobación final. Cada paso guarda una foto de su aprobador y su nivel, para que una reorganización posterior no reescriba la historia.

Ausencias que completan el reporte

Cuando se aprueba una ausencia, las entradas de vacaciones, enfermedad o permiso correspondientes aparecen en el reporte mensual de esa persona, vinculadas a la solicitud que las creó. Nadie carga el mismo día dos veces.

Reportes que se cierran solos

Los reportes mensuales de los pastores se cierran automáticamente una cantidad fija de días hábiles después de fin de mes —salteando feriados—, con recordatorios configurables antes del vencimiento.

Auditar cada página

Auditamos las 23 páginas una por una con un skill propio de Claude Code que maneja Playwright, entrando con sesiones generadas localmente para no tener que automatizar el flujo de inicio de sesión único.

Resultado

  • En producción para la Unión; la primera generación quedó retirada.
  • Alrededor de 520 tests automatizados, 29 modelos de datos y 29 módulos de API.
  • Cada página auditada en comportamiento y permisos.

El código pertenece al cliente y es privado. Las figuras son ilustraciones con datos de ejemplo; en esta página no aparece ningún registro real.