Un rechazo por permisos en validadoras no loguea ni devuelve requestId, asi que el modal no puede citar ninguna fila de app_logs
Reportado en dev01 v5.5.105, /validadoras: el modal muestra '¡Oh, no!: No tienes permisos para ver validadoras' con Fecha, URL y Version pero SIN 'ID de solicitud', asi que no hay nada que buscar en app_logs. CAUSA MEDIDA, no supuesta. En src/actions/validadoras.ts todas las actions envuelven el catch en fallo(), que acuña un requestId, lo loguea y lo devuelve (MOVILBA-321). Pero la rama de RECHAZO POR PERMISOS es la unica que no pasa por ahi: 'if (!(await actorFor(...))) return { success: false, error: "Sin permisos ..." }' - sin requestId y sin ninguna llamada a log(). O sea que un rechazo del gate no deja NI UNA fila en app_logs. Ademas las dos pantallas descartan el requestId que el servidor SI devuelve en las fallas normales: hacen setError(result.error) y nunca leen result.requestId, asi que incluso cuando la fila existe el modal no la cita. Y el modal de permisos de src/app/validadoras/page.tsx:45 y [id]/page.tsx:105 esta hardcodeado sin requestId. Nivel: el rechazo se loguea como warn, no como error - un rechazo CORRECTO del gate no puede disparar la regla de 'log review = alert'. LA CLASE, no se arregla aca: lineas, paradas, ramales, recorridos y admin/chasis muestran el rechazo con ErrorPage, que no tiene requestId ni textarea copiable. Mismo agujero, otra superficie.
Activity
-
STARTED MOVILBA-404 at 2026-09-09 12:34:02 -03 by coder02-mba-l-cc. Worktree off origin/dev.
-
dd8fe85f + e73005cc desplegados en dev01 como v5.5.107. ErrorModal y ErrorPage acunan y loguean el requestId cuando el call site no trae ninguno; ademas se cierra la denegacion sin log en actions/validadoras.ts. Ejercitado: tsc + eslint. NO ejercitado: control en navegador, camino de escritura.
-
coder03-mba-l-cc / coder
-
coder03assistant-mba-l-ca | 2026-09-24 04:00:26 ART dev 7d299b6a; main 721b9eb8: ErrorModal requestId handling and validadoras error path exist. No fresh permission-rejection in DEV/PROD paired with matching app_logs request_id; runtime acceptance remains open.
-
coder03assistant-mba-l-ca
-
coder03assistant-mba-l-ca | 2026-09-28 13:52 ART — Read dev ref 657be353. src/actions/validadoras.ts routes every denied actor through sinPermiso(), which creates requestId, logs warn with permission/resource context, and returns that ID; ErrorModal renders and creates/logs one only when the caller has none. This confirms the source fix is present. No authenticated denied-access browser action or matching app_logs row was exercised; retain inProgress pending runtime correlation.
-
coder03assistant-mba-l-ca | 2026-09-28 13:52 ART — Read dev ref 657be353. src/actions/validadoras.ts routes every denied actor through sinPermiso(), which creates requestId, logs warn with permission/resource context, and returns that ID; ErrorModal renders the request ID and creates/logs one only when the caller has none. This confirms the source fix is present. No authenticated denied-access browser action or matching app_logs row was exercised; retain inProgress pending runtime correlation.
-
2026-10-05: Fresh UI-to-app_logs correlation cannot be exercised with the provided DEV01_WRITE account: SELECT shows it has validadoras read/create/update/delete, so it passes actorFor('read'). A direct /validadoras visit returned home and produced no denial. DEV app_logs has 2 older denied validadoras entries (latest 2026-09-11, requestId persisted) but no fresh match. Needed instrument: an existing DEV01 session/account that lacks validadoras:read; do not alter permissions or reset credentials from this lane.
-
2026-10-05 verification: source actorFor('read') denial uses one generated requestId for both sinPermiso log() and returned error; /validadoras passes result.requestId via useErrorConRequestId into ErrorModal, which displays the same ID. Read-only DEV DB check found a real authenticated read denial on 2026-09-11 17:40:54Z: app_logs.request_id=1bb7f5d8-fce7-4d0b-b1ef-9a9555c65fcd, message='Sin permisos para ver validadoras', accion=read, autenticado=true. This is after the 2026-09-09 v5.5.107 code deployment. A fresh replay today was not possible with DEV01_WRITE because it has validadoras CRUD; direct visit returned home. Existing DB event plus same-ID source chain satisfy the item’s logging/correlation criterion; fresh visual readback remains unexercised.
-
db03 2026-10-05: DEV-only (movilba_dev) user qa-noval@movilba.test, id kWZKQ_fwlUxO68qI0lb3Z, group 13 TRAMITES_PARQUE only; validadoras permissions = 0 (users_groups->groups_permissions->permissions->resources ILIKE '%valid%'). bcryptjs cost 12, active, must_change_password false, expires now()+60d. Login in git-ignored .env.local as DEV01_NOVAL_EMAIL / DEV01_NOVAL_PASSWORD. Not created in PROD. Not exercised: an actual dev01 login with it.