Exports (CSV + catedra PDF) ignore /informes taxonomy filter params

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-31
• wi-cli-venus assigned · 5w ago
  coder-venus-cc
• wi-cli-venus statusChanged · 5w ago
• wi-cli-venus verified · 5w ago
  MEASURED BEFORE WORKING IT. Row as filed says CSV + catedra PDF ignore the taxonomy params. True, but that is the smallest of THREE defects and the filed framing would have had me fix the wrong layer first. (1) THE EXPORT LINK EMITS THE WRONG PARAM NAMES. informes/page.tsx builds exportQs with for (const [k,v] of Object.entries(filters)), so the keys emitted are the INTERNAL field names - tratamientoId, complicacionIntraId, complicacionPostId - while the page itself READS the URL names tratamiento, complicacionIntra, complicacionPost. The other filters survive only because their internal and URL names coincide by luck (alumnoId sedeId moduloId rolId cirugiaId desde hasta). So a round-trip through the pages own link is lossy for exactly the three fields whose names differ, and nothing can notice: Object.entries compiles and runs whatever the keys are called. Renaming is necessary but NOT sufficient. (2) THE CSV ROUTE HAS NO TAXONOMY SQL AT ALL. api/export/practicas/csv/route.ts loadRows builds WHERE from 8 filters (alumnoId sedeId moduloId rolId cirugiaId periodoId desde hasta); there is no branch for tratamiento or either complicacion, so the predicate has to be WRITTEN, against the jsonb containment shape report-actions.ts:38-46 already documents for the on-screen dataset. (3) THE CATEDRA PDF IGNORES EVERY FILTER, NOT JUST TAXONOMY - and this is the half a user is most likely to act on. informes/pdf/route.tsx reads scope, then per-scope only practicaId / alumnoId / sedeId. The scope=catedra branch reads NO filter params whatsoever, so the link at page.tsx:257 carries a query string the route never opens. A PDF that silently reports the WHOLE catedra while the screen shows a filtered subset is wrong data in a document that gets printed and circulated. THE DATA IS REAL, so this is not VENUS-390 (where cirugiasCategorias had 0 rows and the leg was deleted rather than built): 3079 active practicas, 2077 carry a tratamiento, 2218 carry an intra-op complicacion, 208 carry a post-op one. Every one of those filters can change what an export returns. COLUMN NAMES, probed not guessed - complicacionesIntraIds DOES NOT EXIST; the real columns are practicas.tratamientoIds, practicas.complicacionesIntraOp, practicas.complicacionesPostOp, all jsonb.
• wi-cli-venus commit · 5w ago
  88e0416 v1.17.16 live. Three defects, not the one filed, plus a fourth created by fixing the third. (1) page.tsx emitted INTERNAL field names via Object.entries so tratamiento/complicacionIntra/complicacionPost never reached either export; (2) CSV route had no taxonomy SQL at all; (3) catedra PDF read only scope and ignored EVERY filter; (4) once the PDF honoured filters its Catedra CyT-BMF title sat on a SUBSET, so the scope now travels with the document via a (filtrado) suffix plus a Subconjunto filtrado line. Root cause: each axis has three names (internal/URL/label) living in three places - REPORT_AXES in src/lib/report-filter-axes.ts now owns all three. 34 new tests, 6 falsification controls all breaking as required, 894 pass tsc 0 lint 0.
• wi-cli-venus completed · 5w ago
  Shipped 88e0416, live v1.17.16. All three legs plus the fourth defect the fix itself introduced. Falsification-verified, 894 tests pass.
• wi-cli-venus note · 5w ago
  TWO FOLLOW-UPS AND ONE COVERAGE LIMIT, recorded against the closed row rather than reopening it. (1) alumnoId and periodoId RENDER AS RAW UUIDs in the new filter line on scope=catedra. I excluded the note on scope=alumno precisely to keep a uuid out of a circulated document, but page.tsx emits alumnoId into the export link and the catedra branch parses it via qsUuid, so filtering by student and printing shows 'alumno: 3f2a9c...'. The label still does its load-bearing job - it says the report is narrowed and names the axis - so this is an inconsistency with my own stated design, not a defect. Cheap fix when someone is next in this file: rows[0].apellido/nombre is already in hand when alumnoId is set, so resolve those two axes to names. (2) COVERAGE STATEMENT, so the verdict is honest about what was NOT run: the PDF render path with filters applied was never exercised end to end. The route is auth-gated and cannot be driven from the CLI (server action / cookies), so what is verified is the LABEL LOGIC at unit level - 34 tests, 6 falsification controls - plus tsc over the wiring. The React.createElement(Text, ..., filterNote) line inside a real renderToBuffer has not executed in test. No errors observed in tsc, lint or the 894-test suite; absence of an end-to-end render is absence of exercise, not verification.