Ocultar validadoras SUBE/OpenPass en toda la aplicacion - pantalla, formulario, exportaciones y API

Sub-tickets — 8/9 done

Activity

• coder03-mba-l-cc created · 3w ago
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01: parked hole to pick up whenever validadoras are un-hidden. src/services/validadoras-vehiculo.ts:169 reads a fechaExpediente and never calls validarFechaExpediente, so that write path has no date validation at all - no format check and no upper bound, while the colectivo paths have had both since MOVILBA-547 (src/services/vehiculos.ts:101-110). Nothing to change now: the standing rule is that validadoras are HIDDEN and otherwise untouched, and the path is unreachable because src/proxy.ts:136 redirects every validadora screen on every host. Found while retracting MOVILBA-642.
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:25 ART: measured the two 'not measured yet' items the epic itself flagged. (1) History/PDF rendering: already closed by MOVILBA-589 - rutap-history-presentation.ts explicitly excludes subeValidator/subeMountingKit/openpassValidator/openpassMountingKit from the history/PDF surface (in-code comment confirms intent). (2) /api/v1 payload: zero matches for any of the four validadora field names anywhere under src/app/api/v1/ - confirmed not carried. Both epic unknowns are resolved clean; nothing left open here, no decision for Elazar.
• coder03assistant-mba-l-ca statusChanged · 1w ago
  Read-only current-source census underway; no code/DDL changes.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08 source census: /validadoras and descendants redirect at src/proxy.ts:133-139; no current ValidadoraEntitySection imports remain under src/app. Residual code paths need disposition: read server actions at src/actions/validadoras.ts:119-159 still return list/detail/history/options behind actorFor permission checks (:35-40); vehicle-update failure can expose validator IDs via src/services/validadoras-vehiculo.ts:213-223 and src/services/vehiculos.ts:1003-1020. No dedicated validadora API route; no validadora fields found in src/app/api/v1. Export checks: shared XLSX/CSV/PDF columns omit the four fields (src/lib/exports/vehiculos.ts:25-73; /api/v1/exports route uses shared builder); /api/export vehiculos uses RUTAP_LIBRO_COLUMNS and its configured formats (route.ts:34-39,186-203,246-253); historical-report SELECT has no fields; PDF/screen history filter them in src/lib/rutap-history-presentation.ts:9-16,49-63,106-129 and PDF calls same derivation at src/lib/vehiculo-pdf-history.ts:63-82,104. Home cards exclude validadoras at src/app/page.tsx:54-72,107-116. /api/navigation can return DB-derived module metadata from v_navbar_per_user (src/app/api/navigation/route.ts:47-71; src/repositories/navigation.ts:49-94); actual validadoras row presence not queried. No browser/download/live API or DB execution. No data/schema changes.
• researcher-mba-l-cc note · 1w ago
  2026-10-08T18:14:26-03:00 / 21:14:26Z researcher-mba-l-cc. Re-verification census post-742/581/582/589, read-only. Re-grepped column names (sube_mounting_kit, sube_id_validadora, openpass_mounting_kit, openpass_id_validadora) and their camelCase Drizzle aliases across src/, not just known call sites, following the 462 lesson (grep the data, not the already-named surface). CONFIRMED CLEAN: - ValidadoraEntitySection leak sites (lineas/[id], lineas/[id]/editar) - 742 removed both, verified absent. - Screen (HistoryPeriodContent.tsx) and ficha PDF (vehiculo-pdf-history.ts): both call historyDisclosure/deriveHistoryChanges, which filter HIDDEN_PRESENTATION_FIELDS (589's fix) before rendering - subeValidator/subeMountingKit/openpassValidator/openpassMountingKit excluded from both faceBody/changes and the disclosure fallback list. Confirmed at rutap-history-presentation.ts:11-16,52,58,115. - /api/vehiculos/[id]/entidad/history and /linea/history routes: narrow explicit Drizzle selects, no validadora columns at all. - /api/v1/*, exports (parque/export, reportes/vehiculos-historico, liquidacion): already covered by 583, re-confirmed no hits. NEW GAP, not covered by 589 (589's scope was literally "pantalla y PDF"): GET /api/vehiculos/[id]/historia (src/app/api/vehiculos/[id]/historia/route.ts:41) returns toRutapHistorialItems(getRutapHistorialByChain(vehiculoId)) with NO field filtering - item.valores and item.cambios go straight to NextResponse.json unfiltered. periodHistoryValues() (src/lib/rutap-history-values.ts:8-34) builds `valores` from ALL of HISTORY_FIELDS, which includes the four validadora fields with real column mappings and Spanish labels (src/lib/rutap-history-fields.ts:166-181: "ID validadora SUBE", "Kit de montaje SUBE", "ID validadora OpenPass", "Kit de montaje OpenPass"). HIDDEN_PRESENTATION_FIELDS (589) is only applied inside historyDisclosure/deriveHistoryChanges, which this API route never calls - the filtering lives in the UI-consuming functions, not on the data the API serves. Effect: any authenticated session with vehiculos:read can call this route directly and receive the raw SUBE/OpenPass validator id and mounting-kit value for every period where vehiculos_datos_colectivos had them populated, labeled in plain Spanish - no host gate, no field filter, independent of showValidatorFull/isFaithfulHost. This route is also published in the OpenAPI manifest (src/lib/openapi/manifest.ts:807) as a documented external contract endpoint, not an internal-only call - no fetch('/api/vehiculos/.../historia') caller found anywhere in src/, so the ficha screen gets this data some other way (not traced further, out of scope for this census) and this REST path exists purely as the external-facing surface. This directly violates the project's hard rule ("No screen, form, XLSX, PDF, JSON API or navigation entry exposes validadora data") on the one surface type (JSON API) the rule names explicitly and 583/589 did not reach. NOT COVERED: whether any OTHER /api/vehiculos/[id]/* route besides the three checked here reads rutap-historial / periodHistoryValues; live-traffic confirmation (code-reachability finding only, per the 462/742 precedent); whether API docs/Try-it UI (isDevDocsHost) surfaces this route's schema with example values.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08 read-only extension: found an additional JSON leak in GET /api/vehiculos/[id]. src/repositories/vehiculos.ts:501-504 selects getViewSelectedFields(vVehiculosDetalle); drizzle/schema.ts:2318-2321 defines all four SUBE/OpenPass fields on that view; src/app/api/vehiculos/[id]/route.ts:42,51-54 returns the VehiculoDto object directly. This endpoint remains an emitting surface unless it is filtered in a separately scoped change. GET /api/vehiculos/[id]/historia was unfiltered in the 21:14 census, but the current shared tree now has an unverified MOVILBA-753 filter at route.ts:42-47; do not count that as shipped or audited yet. No validadora refs/fields found in api-external/, docs/reference/parque-movil-api/, src/lib/openapi/, /api/v1 routes, or docs Try-it integration: /api/docs renders Scalar from /api/v1/openapi.json (src/app/api/docs/route.ts:1-3,15-16) and the spec exposes no validadora terms. Confirmed clean from prior census: lineas EntitySection removed (742), /validadoras hidden by proxy (582), history screen/PDF filter fields (589), dedicated entidad/linea history endpoints use narrow selects, exports omit fields (583). Residual read actions remain at src/actions/validadoras.ts:119-159 behind RBAC; no live browser/API call performed. Census now identifies /api/vehiculos/[id] as an outstanding JSON surface; keep 753's historia route separate.
• coder03assistant-mba-l-ca blocked · 1w ago
  Read-only census delivered. Remaining JSON API gaps are split into MOVILBA-753 and MOVILBA-754, assigned to coder04; resume the epic after those child fixes are audited/live and reassess the remaining RBAC-gated server actions.
• coder03assistant-mba-l-ca unblocked · 1w ago
  753/754 are audited and closed; resuming the remaining RBAC-gated server-action reassessment.
• coder03assistant-mba-l-ca note · 1w ago
  Post-753/754 reassessment (static only): src/actions/validadoras.ts:119-159 still exports four read actions (getValidadoras, getValidadora, getValidadoraHistory, getValidadorasOptions); each checks auth + hasPermission('validadoras','read') and returns the service data on success. Current source callers are the /validadoras list/detail/add/edit pages (src/app/validadoras/**), all URL paths redirected by src/proxy.ts:133-139. No caller remains from the active app surfaces outside those routes in this grep. Direct Server Action POST reachability after the proxy redirect was NOT exercised, so I cannot claim the read exports are inaccessible; this is the remaining exposure question. No code or DDL change.
• coder03assistant-mba-l-ca progress · 1w ago
  Post-753/754 static reassessment: src/actions/validadoras.ts begins with 'use server' and still exports getValidadoras, getValidadora, getValidadoraHistory, getValidadorasOptions; each checks auth + RBAC read and returns service data on success. Their current UI callers are under /validadoras and redirect via src/proxy.ts:133-139. The proxy matcher includes all paths and returns a 307, which preserves POST; Next 16 action-handler dispatches by action ID and documents cross-route action forwarding. Therefore UI routes are hidden, but source/runtime structure does not establish the read actions as unreachable: a direct POST may follow the 307 to / and dispatch the action for an authorized caller. No live HTTP action invocation or data readback was performed; this remains source-level evidence pending a safe runtime control.
• coder03assistant-mba-l-ca blocked · 1w ago
  The remaining live invocation requires Elazar at an authenticated browser; awaiting that evidence.