Una tarea siempre necesita una actividad contenedora, asi que convertir crea DOS cosas: el
proyecto nuevo y, dentro, una actividad nueva que recibe las tareas -- y comentarios/adjuntos --
de la actividad original. Se piden ambos nombres (precargados con el nombre actual) antes de
confirmar. La actividad original se borra al final, ya vacia de tareas (no choca con el bloqueo
de removeActivity). Exige el mismo permiso que crear un proyecto, no solo escribir la actividad.
Nuevo POST /api/activities/:id/convert-to-project. Probado de punta a punta en dev: prioridad
heredada, tareas y comentario movidos correctamente, actividad original eliminada, navega al
proyecto nuevo al terminar.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Compara la version instalada contra el CHANGELOG.md de main en Gitea (lectura anonima por HTTPS,
sin token) y muestra cada version pendiente con su criticidad -- derivada del digito que cambio
(1ro=Alta, 2do=Media, 3ro=Baja, sin etiquetar nada a mano, regla ya documentada en
VERSIONADO.md), una descripcion breve, y si trae migraciones de base de datos nuevas. Banner en
rojo avisando que la actualizacion requiere reiniciar el sistema.
No instala nada automaticamente -- solo informa. Aplicar la actualizacion (git pull, build,
migrar, reiniciar servicios) sigue siendo manual, a criterio del administrador de cada
instalacion, tal cual DEPLOY_WEB.md ya documenta.
Nuevo GET /api/updater/status (solo superadmin). Requiere que el repo en Gitea sea publico con
vista anonima habilitada -- documentado en DEPLOY_WEB.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Buscador de Proyectos: ahora busca tambien en actividades y tareas de cualquier proyecto (antes
solo nombre/codigo del proyecto). Resultados en un panel flotante con la ruta completa
"Proyecto - Actividad - Tarea"; clic navega al proyecto y abre la actividad encontrada
(pestaña Tareas si el resultado era una tarea).
Buscador de Actividades (dentro de un proyecto): busca tambien en las tareas de esa actividad,
mismo panel con "Actividad - Tarea".
Nuevo GET /api/search?q=...&projectId= (global o acotado a un proyecto). Nuevos componentes/hooks
reutilizables: SearchResultsDropdown, useDebouncedValue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Menu de tres puntos en el listado de Actividades -> elegir proyecto destino -> confirmar
("Se movera la actividad... (junto con sus tareas)... Aceptar/Cancelar) antes de ejecutar.
Tareas, comentarios y adjuntos se mueven solos (referencian la actividad, no el proyecto). Las
dependencias existentes se eliminan al mover -- solo tienen sentido dentro del mismo proyecto
(addDependency ya lo exigia). Nuevo PUT /api/activities/:id/move, exige permiso de escritura en
ambos proyectos (origen y destino).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mismo formato que ya existia en Proyectos. Ordenable por columna; no cambia el orden por
defecto (sigue siendo el orden manual arrastrado con el mouse).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nueva marca configurable desde Configuracion -> Empresa (solo superadmin): nombre y logo,
guardados en system_settings (mismo patron que SMTP, sin tabla nueva). Nuevo endpoint publico
GET /api/company (+ /logo) para que login/registro/recuperacion de clave puedan mostrar la marca
antes de iniciar sesion. Sin configurar, se ve "LinkedCorp" y el logo estatico de siempre.
Probado en dev (build + Playwright: panel de Configuracion, sidebar expandido/compacto, login
publico), sin desplegar a produccion por pedido explicito del usuario -- este commit sirve de
punto de control en git antes de decidir el despliegue.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Columna con fecha y hora, orden por defecto (mas reciente primero) en
vez de fecha de creacion.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Vacio = se repite sin fin (comportamiento previo). Al completar un
ciclo cuyo proximo vencimiento supera "hasta", la tarea se desactiva
sola. Probado en dev con curl (3 ciclos seguidos, se desactiva justo
al superar la fecha) y validacion de que "hasta" no puede ser anterior
al proximo vencimiento.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Menu propio en la barra lateral, independiente de Proyectos:
- Periodicidad configurable (cada N dias/meses/años), proximo
vencimiento, responsable, proyecto de origen opcional.
- "Completar ciclo" avanza el proximo vencimiento sumando la
periodicidad y limpia el recordatorio ya enviado.
- Recordatorio por correo automatico N dias antes del vencimiento
(default 7), a una hora del dia configurable. Un job en el propio
proceso del backend (setInterval cada 15 min) revisa y envia, sin
infraestructura nueva (cron del SO, cola, etc).
- Desde la pestaña Tareas de una actividad, cada tarea tiene un boton
"Convertir en recurrente" que la promueve (la tarea original no se
borra).
Probado en dev con curl (crear, completar ciclo avanza next_due_date,
promover desde una tarea real, disparo real del job de recordatorios
verificado forzando fecha/hora, segunda corrida no reenvia) y Playwright
(listado, popup de creacion, popup de promocion anidado sobre el detalle
de actividad) sin errores de consola.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
El backend ya soportaba filtrar por statusId/priorityId; solo faltaba
exponerlo en la UI. "Proximos a vencer" es client-side, ventana de 7
dias (misma definicion que el KPI del dashboard).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"Agregar dependencia" no daba ninguna señal cuando el combo quedaba vacio
(proyecto con una sola actividad, o ya se agregaron todas las demas) --
se podia percibir como que el boton "no hacia nada". El mecanismo en si
funcionaba bien (verificado con curl y Playwright con 2+ actividades).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Actividad -> Tarea, sin nivel "sub" intermedio (no hay una entidad "Tarea"
de la que estas fueran sub-, asi que el prefijo sobraba). Tabla subtasks
-> tasks (RENAME TABLE idempotente en la migracion 005; 001_initial.sql
tambien actualizado para que una instalacion nueva cree la tabla ya con
el nombre final, sin pasar por el nombre viejo). Modulo backend, rutas,
servicio frontend, pestaña del detalle de actividad, i18n y documentacion
actualizados. Sin cambios de comportamiento, solo nombres.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Al agregar un miembro, el popup ahora permite elegir un usuario existente
o escribir un correo nuevo. Si ese correo no pertenece a nadie, se crea
una cuenta en estado 'invited' (nombre/clave placeholder) y se le manda
un correo con un enlace de un solo uso para que complete su registro
(elige su nombre y clave). La fila de project_members se crea de una vez
al invitar, asi que en cuanto acepta ya es miembro sin pasos adicionales.
A diferencia del autorregistro publico, no pasa por aprobacion de un
admin -- quien lo agrego a su proyecto ya lo vetó.
Nuevos endpoints publicos GET /api/auth/invite y POST /api/auth/accept-invite.
Nueva pagina AcceptInvitePage (/aceptar-invitacion). Migracion 004 agrega
el status 'invited' al enum de users.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Un proyecto puede tener uno o mas administradores (role_in_project=
'admin' en project_members), independiente del rol global del usuario.
Nuevo PUT /api/projects/:id/members/:userId/role; canWriteProject lo
reconoce ademas del comportamiento previo (admin/superadmin/it_manager
global, o project_lead miembro). UI: casilla al agregar miembro + boton
de escudo para promover/degradar (nunca toca al Dueño).
- Menu "Configuracion" (apariencia, catalogos, SMTP) visible y accesible
solo para el superadmin: oculto en el nav y con guarda en la ruta
/configuracion para quien la teclee directo. Escritura de catalogos
restringida de [superadmin, admin] a solo superadmin para que el
backend sea consistente con la UI.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- DELETE /api/projects/🆔 eliminacion logica (deleted_at/deleted_by), mismo
permiso que editar el proyecto. Popup de confirmacion antes de aplicarla.
- Papelera (GET /api/projects?trash=true, POST /:id/restore, DELETE
/:id/permanent) restringida al superadmin; el borrado fisico exige que el
proyecto ya este en la papelera y arrastra actividades/comentarios/adjuntos
por ON DELETE CASCADE.
- Dashboard (KPIs, actividades pendientes/calendario, proyectos por estado)
excluye proyectos eliminados logicamente.
- Columna "Creado" en el listado de proyectos, ordenado por defecto de mas
nuevo a mas antiguo (ListView admite initialSort ademas del orden por clic
en cabecera que ya tenia).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Componente reutilizable PasswordInput (icono de ojo) usado en login, registro,
restablecer clave, cambiar clave, crear usuario y la clave SMTP de
Configuracion, para que el usuario pueda verificar que la esta escribiendo
correctamente.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Agrega POST /api/settings/smtp/test (superadmin, rate-limited) que envia un
correo real usando los valores actuales del formulario y propaga el error
real del servidor SMTP, a diferencia de sendMail() que nunca lanza. El panel
de SMTP ahora tiene un campo de destinatario y boton "Enviar prueba" con el
resultado real (exito o error), en vez de solo "Guardar" sin forma de
verificar que la configuracion funcione.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nuevo PUT /api/auth/change-password: exige la clave actual (a diferencia de
reset-password, que usa un token de correo sin sesion). Opcion "Cambiar clave"
agregada al menu de usuario (popup), disponible para cualquier rol.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- 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>
Antes la lista de miembros del proyecto vivia dentro de la pestaña Info,
mezclada con los campos del proyecto. Se extrae a un componente propio
(ProjectMembersTab) y se agrega como pestaña "Miembros" justo a la derecha
de "Info" en el detalle del proyecto.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Milton Gonzalez