Milton Gonzalez
7557dffc52
- POST /api/auth/register: primer usuario del sistema -> superadmin con sesion directa (bootstrap, sin correo ni aprobacion); los siguientes quedan pending_verification y reciben un correo con enlace de un solo uso (24h). - GET /api/auth/verify-email: pasa a pending_approval y notifica in-app a los admin/superadmin activos. - admin/superadmin aprueban (POST /api/users/:id/approve, eligen rol y departamento) o rechazan (POST /api/users/:id/reject, borra y audita el email) desde Organizacion -> Usuarios (nuevo badge de estado + acciones). - login() da mensaje especifico segun el status de la cuenta en vez del generico "credenciales invalidas". - Recuperacion de clave (forgot/reset-password): respuesta siempre generica, token de 1 hora de un solo uso. - Nuevo modulo settings: SMTP configurable SOLO por superadmin desde Configuracion -> Correo (SMTP); clave cifrada AES-256-GCM (ENCRYPTION_KEY) en la tabla system_settings, nunca expuesta por la API. sendMail() degrada a modo dev (loguea en vez de enviar) si no hay SMTP configurado, y nunca deja que un fallo de envio tumbe al que lo llama. - Migracion 002_registration_and_smtp.sql: rol superadmin, columnas de ciclo de vida en users (status, tokens), tabla system_settings, y promueve al usuario mas antiguo del sistema a superadmin. - Fix: React.StrictMode disparaba el efecto de VerifyEmailPage dos veces; la segunda llamada (token ya consumido) mostraba "enlace invalido" pese a que la verificacion ya habia funcionado. Se agrega una guarda por token. - Fix (deuda tecnica v1.0.0): se reordena el montaje de rutas en app.js — subtasksRoutes (mount generico en /api) va al final, para no interceptar con su requireAuth interno una request sin token dirigida a un router mas especifico registrado despues. - Documentacion actualizada: AGENTS.md, SPEC.md, API.md, BASE_DE_DATOS.md, CONFIGURACION.md, ESTADO.md, CHANGELOG.md. Version 1.1.0. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
124 lines
6.5 KiB
Markdown
124 lines
6.5 KiB
Markdown
# SPEC - project.linkedcorp.net
|
||
|
||
## Objetivo
|
||
|
||
Sistema interno para que una empresa de tamaño medio controle los proyectos y actividades de TI que
|
||
debe cumplir: qué proyectos hay, quién es responsable de qué, qué está atrasado y qué avance real
|
||
tiene cada cosa — sin que cargar la información sea tedioso para quien lo usa día a día.
|
||
|
||
## Problema que resuelve
|
||
|
||
- Hoy no hay un lugar único donde ver proyectos activos, actividades pendientes/vencidas y de quién
|
||
es cada una. El Jefe de TI necesita esa foto al entrar, sin perseguir a cada persona.
|
||
|
||
## Usuarios o roles
|
||
|
||
| Rol | Alcance |
|
||
|---|---|
|
||
| Super Administrador | Todo lo de Administrador + configura el SMTP del sistema. Es el usuario más antiguo (bootstrap automático al registrarse el primero) |
|
||
| Administrador | Todo, incluida gestión de usuarios/roles/catálogos y aprobar/rechazar registros |
|
||
| Jefe de TI | Ve y gestiona todos los proyectos/actividades, aprueba; no administra usuarios |
|
||
| Coordinador / Líder de proyecto | Crea/edita los proyectos donde es responsable o miembro, gestiona sus actividades |
|
||
| Colaborador | Ve y actualiza lo asignado a él (actividades/subtareas propias), comenta |
|
||
| Consultor | Solo lectura en todo |
|
||
|
||
## Modulos (MVP)
|
||
|
||
### 1. Seguridad
|
||
- Login/logout con JWT, sesión persistida en el navegador.
|
||
- Usuarios: alta/edición directa por el Administrador (nombre, email, rol, departamento, cargo,
|
||
activo/inactivo) **o** autorregistro público (`/registro`) con doble candado: el propio usuario
|
||
confirma su correo (enlace de un solo uso, vence en 24h) y luego un Administrador/Super
|
||
Administrador aprueba la cuenta (elige rol y departamento) o la rechaza. El primer usuario que
|
||
exista en el sistema se vuelve Super Administrador automáticamente, sin correo ni aprobación.
|
||
- Recuperación de clave (`/olvide-clave` → `/restablecer-clave`): respuesta siempre genérica
|
||
(no revela si el correo existe), enlace de un solo uso que vence en 1 hora.
|
||
- Correo saliente (verificación/recuperación): SMTP configurable desde Configuración por el Super
|
||
Administrador; sin configurar, el sistema sigue funcionando en modo dev (el enlace se loguea en
|
||
vez de enviarse por correo real).
|
||
- Auditoría central (`audit_log`): quién hizo qué, sobre qué entidad, cuándo.
|
||
|
||
### 2. Organización
|
||
- Departamentos (con sub-área opcional vía `parent_id`, ej. TI → Desarrollo).
|
||
- Usuarios pertenecen a un departamento y tienen un cargo (texto libre).
|
||
|
||
### 3. Proyectos
|
||
- Código autogenerado, nombre, descripción, objetivo, tipo, prioridad, estado, responsable,
|
||
miembros del equipo, fechas (inicio, fin estimado, fin real), % avance (calculado desde las
|
||
actividades), departamento solicitante y responsable, nivel de riesgo (bajo/medio/alto), notas.
|
||
- Estados: Planificado, En preparación, En ejecución, En pausa, Bloqueado, Completado, Cancelado.
|
||
|
||
### 4. Actividades
|
||
- Código, nombre, descripción, responsable, prioridad, estado, fecha inicio, fecha límite, fecha
|
||
real de fin, % avance, marca de hito (`is_milestone`), horas estimadas, dependencias simples
|
||
("depende de" otra actividad del mismo proyecto).
|
||
- Estados: Pendiente, En progreso, En revisión, Bloqueada, En espera, Completada, Cancelada.
|
||
|
||
### 5. Subtareas
|
||
- Checklist liviano dentro de una actividad: nombre, responsable opcional, hecho/no hecho, fecha
|
||
límite opcional. Si una actividad tiene subtareas, su avance se calcula solo desde ellas.
|
||
|
||
### 6. Dashboard
|
||
- KPIs: proyectos activos, proyectos atrasados, actividades pendientes/vencidas/para hoy, avance
|
||
promedio. Lista de actividades vencidas y de hoy del usuario.
|
||
|
||
### 7. Calendario
|
||
- Vista mensual de actividades por fecha límite (incluye hitos marcados).
|
||
|
||
### 8. Gantt
|
||
- Vista de solo lectura por proyecto: barras por actividad (inicio/fin/avance), sin edición directa
|
||
desde el gráfico en el MVP.
|
||
|
||
### 9. Comentarios y adjuntos
|
||
- Hilo de comentarios por proyecto y por actividad.
|
||
- Adjuntar archivos (evidencias) a proyecto o actividad.
|
||
|
||
### 10. Notificaciones
|
||
- In-app (campana con contador): asignación de actividad, actividad vencida/por vencer (job diario),
|
||
cambio de estado relevante.
|
||
|
||
### 11. Configuración
|
||
- Catálogos editables por el Administrador: estados de proyecto, estados de actividad, prioridades,
|
||
tipos de proyecto, departamentos. Vienen con datos semilla — no requieren configuración inicial.
|
||
- Preferencias de interfaz: idioma es-EC/en-US, tema claro/oscuro, apariencia de botones.
|
||
- Correo (SMTP) — visible y editable **solo** por el Super Administrador: host, puerto, usuario,
|
||
remitente y clave (la clave se guarda cifrada y nunca se vuelve a mostrar, solo se sabe si está
|
||
"configurada" o no).
|
||
|
||
## Flujos clave
|
||
|
||
1. Administrador crea departamentos y usuarios (con rol y departamento).
|
||
2. Jefe de TI o Coordinador crea un proyecto, asigna miembros, define fechas y prioridad.
|
||
3. Se crean actividades dentro del proyecto (con responsable, fechas, dependencias si aplica).
|
||
4. Cada responsable actualiza el avance de sus actividades/subtareas; el avance del proyecto se
|
||
recalcula solo.
|
||
5. El Jefe de TI entra al Dashboard y ve de un vistazo activos/atrasados/pendientes/avance.
|
||
6. Vencimientos se marcan automáticamente (🟢 en tiempo / 🟡 próximo a vencer / 🔴 vencido) y generan
|
||
notificación in-app al responsable.
|
||
|
||
## Reglas funcionales importantes
|
||
|
||
- El listado se ve primero; la creación se abre solo con el botón "Nuevo" (regla de UX del grupo).
|
||
- El % de avance de una actividad con subtareas es automático (no editable a mano); sin subtareas,
|
||
es manual (0-100).
|
||
- El % de avance de un proyecto es el promedio del avance de sus actividades (no editable a mano).
|
||
- Una actividad no puede marcarse "Completada" si depende de otra que no lo está (aviso, no bloqueo
|
||
duro en el MVP).
|
||
- Todo texto de interfaz sale de i18n (es-EC/en-US), nunca hardcodeado.
|
||
|
||
## Fuera de alcance por ahora (fase 2+)
|
||
|
||
- Riesgos e Incidencias como módulos propios (hoy: `risk_level`/notas en el proyecto).
|
||
- Solicitudes/requerimientos formales de otras áreas.
|
||
- Recursos (servidores/licencias/software), Proveedores, Presupuesto y costos.
|
||
- Registro de horas trabajadas detallado (bitácora diaria).
|
||
- Reportes exportables (PDF/Excel/CSV) y vista ejecutiva separada.
|
||
- Permisos configurables por módulo × acción desde la UI.
|
||
- Notificaciones por email/WhatsApp.
|
||
- Equipos de trabajo como entidad propia multi-proyecto (hoy: miembros por proyecto).
|
||
|
||
## Estado para produccion
|
||
|
||
- Completado: en desarrollo (MVP en construcción).
|
||
- Bloqueantes: ninguno conocido; deploy a producción pendiente de validación del MVP en local.
|