Nuevas funcionalidades
n-713 Update runner procedure
Repos: api + front + runner · Tipo: Feature · PRs: api #602, front #521, runner #35 · sha: 5203e9f / 8e47534 / f8d5017
Ahora en el tablero podés ver qué versión tiene instalada cada agente (runner) y si quedó desactualizado, sin tener que adivinar. Además cada agente puede actualizarse solo con un comando incluido en su paquete, en lugar de que un operador tenga que re-descargar el ZIP a mano desde el wizard.
1) Conectá un runner por WebSocket con ?version= y ?platform= y verificá que la versión y plataforma quedan guardadas en el Agent (y que NO se actualizan en heartbeat). 2) En el listado de agentes revisá que aparezcan latest_version, is_outdated y el outdated_count en la metadata; un agente con versión desconocida (null) debe figurar como desactualizado. 3) Llamá GET /bots/agents/download-update/?client_id=&platform=: debe validar el agente por client_id + provider de la API key, devolver 409 si ya está en la última versión y respetar el parámetro force. 4) Probá install download con version=latest. 5) Verificá que el ZIP del agente incluye update.cmd/update.sh (y los .ps1 en Windows) y que el pip install sólo corre si cambió el hash de requirements.txt.
Da visibilidad y control sobre el parque de agentes: se sabe qué versión corre cada runner y quiénes están desactualizados, y se habilita la auto-actualización server-side validada, eliminando el proceso manual de re-descarga. Reduce fricción operativa y riesgo de correr versiones viejas del runner a medida que evoluciona junto con cloud-api y cloud-front.
n-717 Separacion logs
Repos: api · Tipo: Feature · PRs: api #599 · sha: 9bef0f9
No hay cambios visibles en la aplicación ni en cómo se usa la plataforma. Es una mejora interna: los registros técnicos del sistema quedan mejor organizados, lo que permite al equipo detectar y resolver problemas más rápido.
Verificar que en cada contenedor se generen los archivos correspondientes: la API escribe en api.log, el worker de tareas en worker.log (incluyendo logs del framework RQ), el scheduler en scheduler.log, y cada consumidor WebSocket en ws_agent.log y ws_user.log respectivamente. Confirmar que api.log incluye el identificador de request [request_id: <id>] y los demás archivos no. Validar que ya no se escribe en django.log, que la rotación a medianoche genera archivos con prefijo de fecha (ej. 20260205_api.log) y que las líneas de WebSocket no se duplican en api.log.
Antes todos los logs del backend (API, tareas en segundo plano, scheduler y WebSockets) se mezclaban en un único archivo, dificultando el diagnóstico. Separarlos por tipo de proceso mejora la operabilidad y acelera la resolución de incidentes, sin afectar el comportamiento de la aplicación ni los contratos HTTP.
n-751 Agregar usuario aprobador opcional en conciliaciones visible en alta edici
Repos: api + front · Tipo: Feature · PRs: api #594, front #514 · sha: 30cdcab / df4da9f
Ahora al crear o editar una conciliación se puede indicar, de forma opcional, quién es el usuario aprobador. El dato queda visible al ver o editar la conciliación. Las conciliaciones existentes no cambian y podés dejar el aprobador vacío si no lo necesitás. La función se muestra solo cuando está habilitada.
Con el feature flag 'conciliation_approver' activo: crear una conciliación seleccionando un aprobador y verificar que se guarda y aparece en detalle y listado (con email y nombre del aprobador). Probar que solo se aceptan usuarios con acceso a la company de la conciliación y que un usuario fuera de alcance, inactivo o eliminado es rechazado con error. Verificar que el selector de usuarios incluye tanto asignables como owners/admins del provider. Con el flag desactivado: confirmar que enviar un aprobador no rompe el alta (se ignora) y que el campo no aparece en las respuestas. Revisar conciliaciones históricas: siguen funcionando con aprobador vacío.
Permite registrar quién aprueba cada conciliación, mejorando trazabilidad y responsabilidad sobre el proceso. Es un cambio opcional y retrocompatible (no afecta datos históricos) y sienta la base para una futura funcionalidad de autorización donde solo el aprobador o un admin pueda abrir/cerrar conciliaciones.
n-752 Restringir abrir y cerrar conciliacion al usuario aprobador o administrado
Repos: api + front · Tipo: Feature · PRs: api #595, front #516 · sha: 74a26a1 / 17ccd02
Cuando una conciliación tiene un aprobador designado, solo ese aprobador (o un administrador/dueño) puede abrirla o cerrarla. Ser el aprobador habilita abrir y cerrar aunque el rol de la persona normalmente no lo permita. Si la conciliación no tiene aprobador, todo sigue funcionando igual que antes.
Con el flag de aprobador activo y una conciliación con aprobador asignado: verificar que el aprobador y un admin/owner pueden cambiar el estado (abrir/cerrar), y que cualquier otro usuario recibe HTTP 403 con mensaje claro. Confirmar que un aprobador con rol sin permiso de grupo (ej. Controlador/Profesional) igual puede abrir/cerrar. Probar el endpoint de candidatos a aprobador (excluye Lectores, admins/owners) y que responde 404 con el flag apagado. Sin aprobador o con flag apagado: comportamiento previo intacto (sin regresiones).
Cierra el hueco de autorización que dejó abierta la tarea previa (N-751): antes cualquier usuario con permiso de grupo podía abrir/cerrar una conciliación con aprobador. Ahora la potestad de estado queda gobernada por el aprobador o la administración, dando control y trazabilidad sobre quién avanza el flujo, sin afectar los casos sin aprobador.
n-753 Agregar campo para adjuntar archivos por registro de conciliacion igual a
Repos: api + front · Tipo: Feature · PRs: api #593, front #513 · sha: 51456e1 / 70c0f12
Ahora en cada registro de una conciliación podés adjuntar un archivo de respaldo (por ejemplo un comprobante, factura o captura), igual que ya se podía en el módulo de Datos. Podés subirlo, reemplazarlo o eliminarlo desde el registro, y el nombre del archivo queda visible en el listado.
Sobre un registro de una conciliación abierta: subir un archivo (PDF/imagen) y verificar que responde 200 con file_url y file_name y que el nombre aparece en el listado paginado. Reemplazar el archivo y confirmar que el anterior se elimina del storage. Eliminar el adjunto y verificar que desaparece. Probar validaciones de tipo MIME, extensión y tamaño máximo (rechazo con archivo inválido/grande), y confirmar que registros antiguos sin adjunto siguen funcionando. Verificar que se requiere permiso de edición y el manejo de bloqueo de la conciliación.
Cierra la paridad funcional con Data Manager: los registros de conciliación ya no quedan sin documentación de respaldo. El frontend (cloud-front) ya tenía la UX lista (paperclip, upload/delete, preview) y esperaba estos endpoints, así que este cambio de backend habilita la funcionalidad completa reutilizando la estrategia de storage Azure/local existente sin duplicar lógica.
n-766 Inferir date input data module
Repos: api + front · Tipo: Feature · PRs: api #597, front #518 · sha: 2c45043 / e74c4f4
Ahora cada columna de un lote del módulo Datos puede tener un tipo definido (texto, número, fecha u opciones) a través de un modelo reutilizable que se asigna al lote. Al cargar o editar registros, el sistema entiende y valida las fechas aceptando varios formatos de entrada y guardándolas de forma uniforme, y avisa cuando un valor no respeta el tipo esperado. En las importaciones, las filas con datos inválidos se saltan sin frenar toda la carga.
Crear un modelo de tipos de dato con líneas por columna (text/number/date/options) desde /api/v1/data-manager/data-type-models/ y verificar que rechaza column_key duplicados. Asignar ese modelo a un lote (data_type_model_id) al crear/editar y confirmar que el detalle del lote devuelve column_types. Guardar y actualizar records con valores válidos e inválidos: los inválidos deben devolver errores por campo en formato { field, message }; probar fechas en distintos formatos y confirmar que se persisten como YYYY-MM-DD. Importar un archivo con filas mixtas y verificar que solo se descartan las filas inválidas sin abortar el job. Validar que los grupos Administrador, Profesional, Controlador y Editor de Datos tienen los permisos *_datatypemodel.
Hasta ahora todas las columnas de un lote se trataban como texto plano, lo que impedía validar formatos y renderizar controles adecuados por columna. Este cambio introduce un catálogo maestro de tipos de dato asociable opcionalmente a cada lote, habilitando validación consistente y normalización de fechas sin romper lotes históricos ni el contrato actual de los registros. Sienta la base para que el frontend pueda ofrecer inputs por tipo (date pickers, numéricos, dropdowns) y mejora la calidad de los datos ingresados.
n-813 Cross batch search board updates
Repos: api + front · Tipo: Feature · PRs: api #600, front #520 · sha: fb6c454 / 1d97e0c
En los resultados de la búsqueda entre lotes de Data Manager ahora se puede operar directamente sobre cada registro (verificar, agregar nota, cambiar estado y asignar responsable), no solo 'Ver'. Qué se puede editar depende del rol de cada usuario, igual que dentro del lote. Además, los registros con valor numérico igual a 0 dejan de aparecer para reducir ruido en los resultados.
Probar la edición desde los resultados con cada rol y confirmar que solo se guardan los campos permitidos: Administrador todos; Editor de Datos (data, nota, verificado, responsable) sin estado manual; Profesional/Controlador (nota, verificado, estado, responsable) sin persistir 'data' del renglón, y Controlador con 'reviewed' cuando hay 2ª validación; Scoped solo estado y responsable; Lector recibe 403 sin cerrar sesión. Verificar que un intento no permitido devuelve el código 'data_manager_record_patch_forbidden' y no un logout genérico. Confirmar que registros con num_search_value == 0 no aparecen en los resultados, mientras que los null/sin mapping numérico sí se mantienen.
La búsqueda entre lotes era de solo lectura y forzaba a navegar al editor del lote para cualquier acción. Se habilita operar sobre los registros desde los propios resultados usando la misma matriz de roles del gestor de lotes (en lugar de un switch binario), y se filtran los valores 0 considerados ruido, agilizando la operación y evitando duplicar la lógica de permisos.
Correcciones
n-815 Conciliador
Repos: api + front · Tipo: Fix · PRs: api #598, front #519 · sha: afdca6e / ffa8eae
Al crear una conciliación con un archivo mal armado (encabezados numéricos, primera fila vacía o una hoja que no existe), ahora recibís de inmediato un mensaje de error claro en lugar de que la pantalla se quede cargando para siempre. Si el procesamiento falla, la conciliación queda marcada como fallida y podés reintentar en vez de esperar sin fin.
Crear una conciliación subiendo archivos inválidos: (1) con headers numéricos, (2) con la primera fila vacía, (3) con una hoja inexistente o no configurada. Verificar que el POST responde 400 con error estructurado (error_code validation_error y mensajes por campo) antes de encolar el job. Luego forzar una falla en el procesamiento async y confirmar que el progreso queda en estado 'failed' (no en 100%) y que el polling del front se detiene correctamente.
Elimina un punto de fricción y de soporte: antes los archivos inválidos hacían fallar el job de forma silenciosa y dejaban al frontend en un loop de polling infinito. Ahora la validación es fail-fast en el POST y hay un estado terminal de error, mejorando la experiencia de creación de conciliaciones y la integración front/back con contratos de error claros.
n-818 Logs se cortan
Repos: api + front · Tipo: Fix · PRs: api #596, front #517 · sha: 95bf79c / f0b56d7
Ahora podés ver y descargar el log completo de una ejecución de bot, no solo el tramo final. Antes las ejecuciones largas (por ejemplo conciliaciones con miles de líneas) se mostraban cortadas y no se podía revisar todo lo que pasó; ahora el registro completo queda disponible desde la vista de la ejecución.
Ejecutar un bot que genere un log grande (miles de líneas / varios MB) y verificar: que al finalizar (éxito, error o cancelación) el archivo completo queda disponible para descargar y que el contenido coincide con el del agente; que el estado en tiempo real sigue mostrando el tramo final; que la descarga y la vista previa muestran el log completo y no solo los últimos 4 KB; que se respeta el límite de tamaño (50 MB por defecto) y que al aplicar la retención/truncado se elimina también el archivo almacenado.
Los logs de ejecución se truncaban a 4 KB en el transporte runner→WebSocket, impidiendo analizar ejecuciones largas pese a existir el log completo en el agente. Se agrega subida/almacenamiento y descarga del log completo (con autenticación por API key del agente, control por tenant y límite de tamaño), habilitando el diagnóstico real de ejecuciones extensas sin perder el estado en tiempo real.
n-833 Text search value num search value no se calculan al crear un registro en
Repos: api · Tipo: Fix · PRs: api #601 · sha: feb6540
Cuando agregás un registro nuevo a un lote del Data Manager que tiene configurada la búsqueda por columnas, ese registro ahora aparece de inmediato en la búsqueda entre lotes. Antes quedaba invisible hasta editarlo manualmente.
En un lote con mapping de búsqueda configurado (columna de texto y numérica), crear un registro nuevo por la UI del portal o vía POST .../data-manager/data/{batch_id}/record/. Verificar que la respuesta y el registro guardado traen text_search_value y num_search_value calculados (no null) y que el registro es encontrable en la búsqueda cross-batch sin editarlo. Probar también: lote sin mapping deja ambos valores en null; clave numérica no numérica cae a null; valores enviados por el cliente se ignoran (el server los calcula).
Cierra un hueco del rollout de búsqueda cross-batch: la creación de registro individual era el único flujo que no poblaba los campos denormalizados (import y PATCH ya lo hacían), por lo que registros nuevos quedaban fuera de los resultados de búsqueda hasta un workaround manual. El fix da consistencia y hace la búsqueda confiable sin pasos extra del usuario.