Ficha de vehiculo: desplegable de modificaciones que muestre TODOS los cambios, no solo los que tienen expediente

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus assigned · 2026-08-20
  coder02-mba-l-cc / coder
• wi-cli-venus note · 2026-08-20
  audit-mba-l-ca review 2026-08-20: current vehicle page PDF history does not mirror the screen. PDF omits inferred Evento, Motivo, Expediente de baja, decoded before/after cambios, periodoHasta/validity interval, and registrar details rendered by ExpedienteForm. PDF also omits screen Fecha de Alta in Información Operativa. This is a concrete scope/drift finding for the requested history/PDF work; no PROD risk identified.
• wi-cli-venus parentChanged · 7w ago
  parent=MOVILBA-125
• wi-cli-venus spec · 6w ago
  Respuesta de Eugenia, recogida del tracker el 2026-09-01 (asunto 36, hoja Para Eugenia; llevaba tiempo contestada en la columna 'Tu respuesta' con el estado todavia en 'Aguardando', nadie la barrio). Le preguntamos que columnas necesitaba ver en cada renglon del historial de cambios, en que orden, y si tenia que verse igual que en la app. Contesto textual: 'El ultimo expediente que recibimos=el mas reciente mas arriba.' ESPECIFICACION QUE SE DESPRENDE: el historial se ordena por fecha DESCENDENTE, el cambio mas reciente arriba de todo, y el mismo orden vale para la app y para el informe en PDF. No dio lista de columnas, asi que la elegimos nosotros; si hiciera falta confirmarla se pregunta aparte y acotado, no se reabre el asunto entero. OJO con el criterio de orden: creado_en NO es orden de escritura en 2441 de 4052 filas de vehiculo_historial (MOVILBA-113) y es CONSTANTE por lote de import. Ordenar 'lo mas reciente arriba' por creado_en da un orden arbitrario dentro de cada lote. El orden tiene que salir de la fecha de negocio del tramite.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• coder03-mba-l-cc assigned · 2w ago
  coder04-mba-l-ca
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• researcher-mba-l-cc statusChanged · 1w ago
  researcher-mba-l-cc claiming per coder03's 2026-10-08 reassignment: spec the data source and the rows it would show for one dominio with app edits, no code.
• researcher-mba-l-cc note · 1w ago
  researcher-mba-l-cc 2026-10-08T11:48:43-03:00 — spec, no code. Dependencies both closed (MOVILBA-12 done 2026-10-08, MOVILBA-46 done 2026-10-06), so the historial is safe to show per the ticket's own gating. DATA SOURCE (already built, no new query needed): src/actions/vehiculos.ts:getVehiculoHistorial(vehiculoId) -> src/repositories/rutap-historial.ts:getRutapHistorialByChain. Confirmed by reading the function body: - WHERE h.borrado_en IS NULL AND (h.origen = 'app' OR <latest-snapshot import row>) — NO filter on expte_alta/expte_baja anywhere in the query. The code's own comment states it directly: "app-owned events are durable history and are included regardless of snapshot." This already satisfies the ticket's core ask (todos los cambios, no solo los que tienen expediente) at the data layer. - Walks the FULL chasis chain (v_vehiculo_cadena), not just the queried vehiculo_id, per MOBAAPI-689 — a replate/chain change shows every linked vehicle's events, not only the current one's. - Server returns business-ASCENDING order (fecha_alta, fila del libro, never creado_en per commons s12); a comment at rutap-historial.ts:131 says the ficha reverses it to newest-first. This already matches Eugenia's 2026-09-01 spec verbatim ('el ultimo expediente que recibimos = el mas reciente mas arriba'). - Catalog FKs resolve against the PERIOD's own id (not the vehicle's current selection), so a retired/renamed catalog value in an old row still shows its period-correct label — relevant because an app-edited row with no expediente will often carry a changed catalog FK (tramite_id, estado_id) that still needs correct resolution. THE ACTUAL GAP IS NOT THE QUERY, IT'S THE UI: grepped src/app/vehiculos/[dominio]/page.tsx and every src/components/*.tsx for a rendered historial dropdown on the vehicle ficha — found none. getVehiculoHistorial is called exactly once in the whole page, inside handleExportPDF, to build the PDF payload only. There is no on-screen desplegable today; HistoryPeriodContent (the closest-named component) is wired into ExpedienteForm, a different screen (entidad/chofer expediente editing), not the vehicle ficha. So this ticket is a net-new UI build consuming an already-correct, already-tested data source — not a filter to remove from an existing dropdown. ROWS FOR ONE DOMINIO WITH APP EDITS (structural trace, not a live DB pull — I have no DB access; db-lane can supply an actual printout for a named dominio if wanted): each HistorialItem the component would receive carries origen ('app'|'import'), fechaAlta, fechaBaja, tramite + tramiteNombre (resolved only against grupo_nombre='vehiculo_historial'/campo_nombre='tramite', MOVILBA-308-qualified), expteAlta/expteBaja (empty string on an app edit with no case file — toRutapHistorialItems/clasificarExpediente already renders empty as 'Sin expediente', confirmed in src/lib/historial-vehiculo.ts and HistoryPeriodContent.tsx, no special-case needed), entidadNombre, lineaNumero, a typed diff ('cambios') against the previous event in the chain, and the catalog-resolved display fields (chassisMake/Model, body/bodyModel, vehicleType, serviceType). An app-origin row with no expediente differs from an import row only in `origen` and in typically-empty expte fields — every other column already resolves identically, so the dropdown needs no origen-specific branch beyond what 'Sin expediente' already provides elsewhere in the codebase. RECOMMENDATION (not a decision): build the dropdown as a thin consumer of the existing getVehiculoHistorial(vehiculoId) result on the ficha page (fetch on mount, not only on PDF export), rendering the same row shape HistoryPeriodContent/toRutapHistorialItems already produce for the PDF, newest-first. No migration, no view change, no repository change. Not done: no live pull of an actual dominio's rows (needs db-lane); did not check the PDF/XLSX column-order the ticket also mentions, since Eugenia's spec event already settled it (DESC, mirror app and PDF) and the audit note from 2026-08-20 (PDF omits several screen fields) is about a DIFFERENT PDF defect, not this ticket's data-source question.
• researcher-mba-l-cc blocked · 1w ago
  researcher-mba-l-cc 2026-10-08T11:48:43-03:00 spec posted. Parked: building the UI is a coder task now that the spec confirms the data source needs no change; not mine to build.
• coder03-mba-l-cc assigned · 1w ago
  coder04-mba-l-ca / coder
• coder04-mba-l-ca note · 1w ago
  2026-10-08 source correction to researcher spec: src/app/vehiculos/[dominio]/page.tsx:1605-1606 already renders <ExpedienteForm vehiculoId={id}> on the ficha. src/components/ExpedienteForm.tsx:47-64 calls getVehiculoHistorial on mount, :152-155 defaults to all rows (no expediente predicate), :158-259 renders Historial del Vehículo and per-row content; src/lib/rutap-historial-api.ts:76 reverses the business-ascending query to newest-first. Thus the claimed net-new UI gap does not hold in current code. Need one PROD screen check of an app-origin row with blank expediente before deciding whether 71 is done or a narrower UI defect remains; no code change yet.
• coder04-mba-l-ca progress · 1w ago
  DEV screen control assigned to proxy: LB002EP (vehiculo 6810), four app-origin periods with blank expediente in movilba_dev. Existing ficha ExpedienteForm renders getVehiculoHistorial without expediente filter; awaiting DEV screenshot to confirm rows are visible/newest-first before closing or narrowing.
• coder04-mba-l-ca note · 1w ago
  Additional PROD control already saved by proxy at /data-lezama/movilba/evidencia/MOVILBA-71/movilba71-prod-aa734qs.txt (2026-10-08 ~11:52 ART, build 5.6.186): AA734QS ficha renders all five history rows newest-first, including two rows labeled Sin expediente. This supports the no-expediente display path but is not the requested DEV app-origin control; LB002EP screen capture remains pending.
• coder04-mba-l-ca note · 1w ago
  2026-10-08 DEV read-only correction: LB002EP no longer has blank expedientes in the screen and is retired as a control. Fresh query found live ZX006ZX (vehiculo 6794, borrado_en NULL) with app-origin historial IDs 286682/286683/286684; expte_alta and expte_baja are NULL on all three. Proxy has this exact domain for ficha screen capture. If the screen shows fewer than three, narrow the defect to history assembly rather than assuming the data source is blank.
• coder04-mba-l-ca verified · 1w ago
  DEV browser control, 2026-10-08, build 5.6.189: ZX006ZX (vehiculo 6794) ficha Historial del Vehículo shows exactly three app-origin periods, all Expediente de alta: Sin expediente, matching historial IDs 286682/286683/286684 measured read-only. Two ADMINISTRATIVO rows and one ALTA row appear in order with their changes/details; no expediente-based exclusion. Screenshot independently inspected: /data-lezama/movilba/evidencia/MOVILBA-71/movilba71-dev-zx006zx-historial.jpg. PROD AA734QS control also shows five rows including two Sin expediente; evidence at /data-lezama/movilba/evidencia/MOVILBA-71/movilba71-prod-aa734qs.txt. Requested behavior already live; no code change.
• coder04-mba-l-ca unblocked · 1w ago
• coder04-mba-l-ca completed · 1w ago
  Current ficha already renders every history period regardless of expediente. DEV ZX006ZX app-origin blank-expediente 3/3 visible on build 5.6.189; PROD AA734QS blank-expediente 2/2 visible. Screenshot and read-only row controls recorded in verified event. No code or DB change.