diff --git a/.gitignore b/.gitignore index fb2685d..519cd44 100644 --- a/.gitignore +++ b/.gitignore @@ -5,11 +5,18 @@ /tmp /out-tsc /bazel-out +/build +backend/dist +backend/build # Node /node_modules +backend/node_modules npm-debug.log yarn-error.log +pnpm-debug.log* +yarn-debug.log* +lerna-debug.log* # IDEs and editors .idea/ @@ -33,9 +40,13 @@ yarn-error.log .sass-cache/ /connect.lock /coverage +backend/coverage +backend/.nyc_output /libpeerconnection.log testem.log /typings +.temp +.tmp # System files .DS_Store @@ -43,4 +54,22 @@ Thumbs.db .sonarlint .vscode .scannerwork -package-lock.json \ No newline at end of file +package-lock.json +backend/package-lock.json +**/.claude/settings.local.json + +# Environment variables +.env +.env.development.local +.env.test.local +.env.production.local +.env.local + +# Runtime data +pids +*.pid +*.seed +*.pid.lock + +# Diagnostic reports +report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json \ No newline at end of file diff --git a/HU - definiciones(1).txt b/HU - definiciones(1).txt new file mode 100644 index 0000000..7f07c51 --- /dev/null +++ b/HU - definiciones(1).txt @@ -0,0 +1,276 @@ +********************************************************************* +EP01 – Ingresar al Sistema +El objetivo es comprobar la autenticidad del usuario. Los usuarios serán los analistas técnicos de la unidad de concesiones, la jefatura de dicha unidad y un usuario de la Unidad de Información. +--------------------------------------------------------------------- +EP01.HU01 – Implementar servicio validación de usuario +COMO Desarrollador +QUIERO crear un servicio que valide usuario +PARA Permitir acceder al sistema + +CRITERIOS DE ACEPTACIÓN +- Debe recibir como parametros USUARIO (correo electronico) y CONTRASEÑA. +- Debe validar formato correo electronico. +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/login). +- El servicio debe conectarse a una fuente de datos (LDAP). +- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara. +- La respuesta debe entregar el ROL del usuario validado dentro del sistema. +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +--------------------------------------------------------------------- +EP01.HU02 – Autenticar usuario +COMO Usuario +QUIERO Ingresar mi correo electronico institucional y mi contraseña en un formulario de acceso +PARA Que el sistema valide mi identidad y me permita acceder a mi cuenta personal de manera segura. + +CRITERIOS DE ACEPTACIÓN +1. Debe existir un formulario con campos obligatorios de usuario y contraseña. +2. El sistema debe validar que ninguno de los campos esté vacío. +3. Si el usuario o la contraseña son incorrectos, se mostrará un mensaje de error (por definir) +4. Si las credenciales son válidas, el usuario será redirigido al panel principal del sistema. +5. Si las credenciales son válidas, el sistema deberá desplegar las opciones de MENÚ habiltadas para el ROL del usuario logueado. +********************************************************************* +EP02 – Pantalla de Usuario Administrador Unidad de Concesiones +El objetivo es mostrar de forma consolidada las cargas temporales del PR047, para que un usuario administrador asigne cronogramas a los analistas y se notifique. Además, que permita realizar solicitud de carga a la Unidad de Información y notifique a la empresa. +--------------------------------------------------------------------- +EP02.HU01. Implementar servicio asignación de cronograma +COMO Desarrollador +QUIERO Crear un servicio que asigne cronogramas +PARA Perimtir asignar cronogramas a un analista. + +CRITERIOS DE ACEPTACIÓN +- Debe recibir como parametros el identificador del cronograma y del analista. +- Debe generar los registros que sean necesarios en la base de datos. +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/asignar). +- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.). +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +--------------------------------------------------------------------- +EP02.HU02. Implementar servicio de solicitudes de carga +COMO Desarrollador +QUIERO Crear un servicio que solicite la carga de ¿cronogramas? +PARA Perimtir solicitar la carga de nuevos ¿cronogramas? a la unidad de información. + +CRITERIOS DE ACEPTACIÓN +- Debe recibir como parametros el identificador del ¿cronograma? que se desea cargar. +- Debe generar los registros que sean necesarios en la base de datos. +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/solicitudcarga). +- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.). +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +--------------------------------------------------------------------- +EP02.HU03. Cargar cronogramas +--------------------------------------------------------------------- +EP02.HU04. Implementar filtros +--------------------------------------------------------------------- +EP02.HU05. Asignar cronograma +--------------------------------------------------------------------- +EP02.HU06. Implementar semaforo +--------------------------------------------------------------------- +EP02.HU07. Solicitar carga de cronogramas +--------------------------------------------------------------------- +EP02.HU08. Notificar a Unidad de Información +********************************************************************* +EP03 – Vista de Carga de Cronograma Temporal por Actualización de PD +El objetivo es desplegar la carga temporal de los cronogramas de actualización de PD o nuevas concesiones para cada analista, aprobar o rechazar la carga, añadir comentarios generales y/o por cada glosa, notificar a la empresa cuando se rechace la carga y exportar los datos a un archivo pdf. +--------------------------------------------------------------------- +EP03.HU01. Implementar servicio de gestión de glosas (aprobación/rechazo) +--------------------------------------------------------------------- +EP03.HU02. Implementar servicio para exportar datos a Excel +--------------------------------------------------------------------- +EP03.HU03. Cargar cronogramas +--------------------------------------------------------------------- +EP03.HU04. Implementar filtros +--------------------------------------------------------------------- +EP03.HU05. Aprobar carga +--------------------------------------------------------------------- +EP03.HU06. Rechazar carga +--------------------------------------------------------------------- +EP03.HU07. Ingresar observación +--------------------------------------------------------------------- +EP03.HU08. Exportar a Excel +--------------------------------------------------------------------- +EP03.HU09. Notificar a empresa +********************************************************************* +EP04 – Vista de Carga de Cronograma Temporal por Ajuste de PD +EP04.01. Implementar servicio para obtener listado de ajustes y amplicaciones +--------------------------------------------------------------------- +EP04.HU02. Cargar cronogramas +--------------------------------------------------------------------- +EP04.HU03. Cargar ajustes PD y ampliación TO +--------------------------------------------------------------------- +EP04.HU04. Implementar filtros +--------------------------------------------------------------------- +EP04.HU05. Ingresar observación +--------------------------------------------------------------------- +EP04.HU06. Aprobar carga +--------------------------------------------------------------------- +EP04.HU07. Rechazar carga +--------------------------------------------------------------------- +EP04.HU08. Exportar a Excel +--------------------------------------------------------------------- +EP04.HU09. Exportar a PDF +--------------------------------------------------------------------- +EP04.HU10. Notificar a empresa +********************************************************************* +EP05 – Vista de Resumen +EP05.HU01. Implementar switch vistas +--------------------------------------------------------------------- +EP05.HU02. Cargar cronogramas aprobados +--------------------------------------------------------------------- +EP05.HU03. Cargar cronogramas rechazados +--------------------------------------------------------------------- +EP05.HU04. Implementar filtros +--------------------------------------------------------------------- +EP05.HU05. Generar PDF para firma digital (x2) +--------------------------------------------------------------------- +EP05.HU06. Notificar a empresa +********************************************************************* +EP06 – Vista para Usuario de Unidad de Información +EP06.HU01. Cargar cronogramas pendientes de carga +--------------------------------------------------------------------- +EP06.HU02. Cargar cronogramas aprobados +--------------------------------------------------------------------- +EP06.HU03. Cargar cronogramas rechazados +********************************************************************* +EP07. Servicios transversales +EP07.HU01. Implementar servicio listado de cronogramas por estado +COMO Desarrollador +QUIERO Crear un servicio que devuelva una lista de cronogramas por estado +PARA Ser cargados/consultados por la funcionalidad que lo requiera. + +CRITERIOS DE ACEPTACIÓN +- El servicio debe retornar todos los registros +- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde) +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/cronogramas/listado). +- El servicio debe conectarse a la fuente de datos correspondiente. +- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara. +- Debe implementar paginación para manejar grandes volúmenes de datos. +- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado'). +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.). +--------------------------------------------------------------------- +EP07.HU02. Implementar servicio listado empresas +COMO Desarrollador +QUIERO Crear un servicio que devuelva una lista de empresas +PARA Ser cargados/consultados por la funcionalidad que lo requiera. + +CRITERIOS DE ACEPTACIÓN +- El servicio debe retornar todos los registros +- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde) +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /empresas). +- El servicio debe conectarse a la fuente de datos correspondiente. +- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara. +- Debe implementar paginación para manejar grandes volúmenes de datos. +- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado'). +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.). +--------------------------------------------------------------------- +EP07.HU03. Implementar servicio listado ajustes PD +COMO Desarrollador +QUIERO Crear un servicio que devuelva una lista de ajustes de PD +PARA Ser cargados/consultados por la funcionalidad que lo requiera. + +CRITERIOS DE ACEPTACIÓN +- El servicio debe retornar todos los registros +- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde) +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ajustespd). +- El servicio debe conectarse a la fuente de datos correspondiente. +- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara. +- Debe implementar paginación para manejar grandes volúmenes de datos. +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.). +--------------------------------------------------------------------- +EP07.HU04. Implementar servicio listado ampliación TO +COMO Desarrollador +QUIERO Crear un servicio que devuelva una lista de ampliación de TO +PARA Ser cargados/consultados por la funcionalidad que lo requiera. + +CRITERIOS DE ACEPTACIÓN +- El servicio debe retornar todos los registros +- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde) +- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ampliacionto). +- El servicio debe conectarse a la fuente de datos correspondiente. +- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara. +- Debe implementar paginación para manejar grandes volúmenes de datos. +- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.). +- Los errores además, deben presentar mensajes descriptivos. +- Considerar seguridad (token, roles, etc.) si aplica. +- Aplicar principios de clean code y separación de responsabilidades. +- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.). +--------------------------------------------------------------------- +EP07.HU05. Implementar servicio notificaciones +COMO Desarrollador +QUIERO Crear un servicio que envie correos electronicos +PARA Notificar a quien corresponda respecto de alertas o confirmaciones. + +CRITERIOS DE ACEPTACIÓN +- El servicio debe aceptar al menos los siguientes parámetros: + - Destinatario(s) + - Asunto + - Cuerpo del mensaje (HTML o texto plano) + - Remitente (opcional, configurable) +- Debe realizar validaciones básicas (formato de email, campos requeridos). +- Debe manejar errores como correos inválidos, errores de red, o problemas con el servidor SMTP. +- El servicio debe retornar respuestas con códigos HTTP claros (200, 400, 500, etc.). +- El envío debe ser asincrónico si se anticipa alto volumen (opcional). +- Debe registrar los envíos en logs o base de datos (para trazabilidad, opcional). + +--------------------------------------------------------------------- +********************************************************************* + +generar epica de servicios transversales +por cada HU generar su propio exportar a excel +generar servicio por cada pdf a generar +no incluir botonera de switch de vistas +generar matriz de autorizaciones (perfil, pantalla) + + + + + + + +--- + +### ✅ **Criterios de Aceptación:** + +- Se debe crear un endpoint (por ejemplo, `POST /api/email/send`) que reciba los datos del correo. + +--- + +### 🔁 **Flujo Básico de Desarrollo:** + +1. Diseñar el endpoint REST (por ejemplo, en .NET, Node.js, Spring Boot). +2. Configurar un proveedor de correo (SMTP, SendGrid, Mailgun, etc.). +3. Implementar la lógica de envío y validación. +4. Manejar errores y respuestas. +5. Agregar logs y/o almacenamiento de eventos. +6. Probar con diferentes escenarios y correos de prueba. + +--- + +### 🛠️ **Notas Técnicas:** + +- Se recomienda usar una biblioteca estándar de envío de correo según el lenguaje (ej. Nodemailer en Node.js, MailKit en .NET, JavaMail en Java). +- Usar plantillas de email si se requiere formato HTML. +- Considerar seguridad: autenticación con el proveedor, evitar inyecciones, validar origen de llamadas. +- Considerar colas de mensajes si se requiere alta disponibilidad (ej. RabbitMQ, Azure Service Bus). + +--- + +¿Te gustaría que prepare una versión adaptada para .NET Core, Node.js o algún otro stack específico? \ No newline at end of file diff --git a/Requerimientos_vista PR047.docx b/Requerimientos_vista PR047.docx new file mode 100644 index 0000000..9329cf6 Binary files /dev/null and b/Requerimientos_vista PR047.docx differ