Files
project.linkedcorp.net/API.md
T
Milton Gonzalez 7557dffc52 feat: autorregistro con verificacion de correo + aprobacion, superadmin y SMTP
- 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>
2026-09-05 23:28:46 -05:00

4.3 KiB

API - project.linkedcorp.net

Base URL

  • Desarrollo: http://localhost:4019/api
  • Producción: https://project.linkedcorp.net/api

Autenticacion

  • Tipo: Bearer JWT (Authorization: Bearer <token>), emitido por /api/auth/login.
  • El backend revalida is_active del usuario en cada request (no solo la firma del JWT).

Formato de respuesta

{
  "success": true,
  "data": {},
  "error": null
}

Endpoints principales

Auth

  • POST /api/auth/login — { email, password } → { token, user }. Si el usuario no esta active (pending_verification/pending_approval) o is_active=0, 403 con mensaje especifico.
  • POST /api/auth/register — público. { name, email, password } → si es el primer usuario del sistema: { bootstrap: true, token, user } (superadmin, sesion directa); si no: { bootstrap: false } y se envia (o loguea, sin SMTP) un correo de verificación.
  • GET /api/auth/verify-email?token=... — público. Pasa el usuario a pending_approval y notifica in-app a los admin/superadmin activos.
  • POST /api/auth/forgot-password — público. { email } → respuesta siempre genérica.
  • POST /api/auth/reset-password — público. { token, password }.
  • POST /api/auth/logout
  • GET /api/auth/me — usuario actual

Usuarios (/api/users) — lectura para cualquier autenticado; escritura solo Administrador/Superadministrador

  • GET /api/users · POST /api/users · PUT /api/users/:id · PATCH /api/users/:id/active
  • POST /api/users/:id/approve — { roleId?, departmentId? }, solo sobre usuarios pending_approval
  • POST /api/users/:id/reject — borra al usuario pending_approval (se audita el email antes)

Departamentos (/api/departments)

  • GET /api/departments (árbol) · POST /api/departments · PUT /api/departments/:id · DELETE /api/departments/:id

Proyectos (/api/projects)

  • GET /api/projects (filtros: estado, responsable, prioridad) · POST /api/projects
  • GET /api/projects/:id · PUT /api/projects/:id
  • POST /api/projects/:id/members · DELETE /api/projects/:id/members/:userId

Actividades (/api/activities)

  • GET /api/projects/:projectId/activities · POST /api/projects/:projectId/activities
  • GET /api/activities/:id · PUT /api/activities/:id
  • POST /api/activities/:id/dependencies · DELETE /api/activities/:id/dependencies/:dependsOnId

Subtareas (/api/activities/:activityId/subtasks)

  • GET · POST · PUT /api/subtasks/:id · PATCH /api/subtasks/:id/done · DELETE /api/subtasks/:id

Comentarios (/api/comments)

  • GET /api/comments?entityType=project&entityId=1 · POST /api/comments

Adjuntos (/api/attachments)

  • GET /api/attachments?entityType=activity&entityId=1 · POST /api/attachments (multipart)
  • GET /api/attachments/:id/download · DELETE /api/attachments/:id

Notificaciones (/api/notifications)

  • GET /api/notifications · PATCH /api/notifications/:id/read · PATCH /api/notifications/read-all

Dashboard (/api/dashboard)

  • GET /api/dashboard/summary — KPIs (activos, atrasados, pendientes/vencidas/hoy, avance promedio)
  • GET /api/dashboard/calendar?month=2026-09 — actividades por fecha límite
  • GET /api/projects/:id/gantt — actividades con fechas/avance para el Gantt

Catálogos (/api/catalogs) — lectura general, escritura solo Administrador

  • GET/POST/PUT/DELETE /api/catalogs/project-statuses
  • GET/POST/PUT/DELETE /api/catalogs/activity-statuses
  • GET/POST/PUT/DELETE /api/catalogs/priorities
  • GET/POST/PUT/DELETE /api/catalogs/project-types

Auditoría (/api/audit) — solo Superadministrador / Administrador / Jefe de TI

  • GET /api/audit?entityType=project&entityId=1

Configuración SMTP (/api/settings) — solo Superadministrador

  • GET /api/settings/smtp — { host, port, user, from, configured } (nunca la clave)
  • PUT /api/settings/smtp — { host, port, user, from, pass? } (pass vacío = no cambiarla)

Errores esperados

  • 400 validación
  • 401 no autenticado / token inválido o expirado
  • 403 sin permisos para la acción (según rol)
  • 404 no encontrado (incluye cuando el recurso existe pero no pertenece al usuario/alcance)
  • 500 error interno (sanitizado, sin detalle de stack en producción)