Crear el recurso RBAC 'reportes' y asignarlo a grupos
PRIMER PASO del epic MOVILBA-158: sin esto la tarjeta Reportes no se renderiza para nadie y la ruta no se puede gatear. Medido en DEV 2026-08-31 (SELECT): la tabla resources tiene 21 filas y NINGUNA se llama 'reportes'. src/app/page.tsx:64 declara la tarjeta con clave RBAC 'reportes', y src/lib/rbac.ts resuelve permisos por users_groups -> groups -> groups_permissions -> permissions -> resources. Sin la fila en resources, hasAccess('reportes') es false siempre. TRABAJO: filas en resources + permissions + groups_permissions. Es DML de datos de RBAC, no DDL de esquema. DECISION PREVIA (la toma el diseño del epic, no este item): granularidad. Un solo recurso 'reportes' con acciones read/create/export, o un recurso por reporte. Un recurso unico es mas simple pero no permite dar un reporte y negar otro; uno por reporte permite eso pero multiplica filas por cada reporte nuevo. No ejecutar hasta que el catalogo de reportes este definido, porque la respuesta depende de cuantos reportes hay y de si se reparten distinto por grupo. Grupos reales a considerar (DEV): ADMIN(11), VEHICULOS_VIEWER(12), TRAMITES_PARQUE(7), DEV_SR(3), VIEWER(2), 'API Docs'(2), EDITOR(0), EDITOR_INSTALACIONES(0), usuarios_desactivados(0). DEV y PROD por separado, cada uno con GO fresco. Comparar el set de filas contra PROD antes de escribir: los ids de resources no coinciden necesariamente entre entornos.
Activity
-
parent=#3162
-
db03-mba-l-cc
-
db02-mba-l-cc
-
db02-mba-l-cc, 2026-09-12: agrupacion para la propuesta de escritura (detalle en MOVILBA-190). Este item va en el GRUPO DE PERMISOS junto con 173 y 230, que son las otras dos escrituras de RBAC/GRANT pendientes, pero se ejecuta APARTE de las otras dos: 160 crea un recurso de aplicacion y lo asigna a grupos; 173 es un control positivo sobre GRANT que ya estan puestos en PROD (medido hoy: svc_nextjs YA tiene CRUD y USAGE sobre las tres tablas de validadoras, o sea la premisa de 173 caduco); y 230 no es solo agrupar roles - hay 3 roles con nombre de identificacion tributaria que tienen privilegio COMPLETO directo sobre 55 objetos y 2 que son SUPERUSER, asi que meterlos en un grupo de lectura no les saca nada. Los tres comparten revisor y ventana, no transaccion.
-
Elazar GO 2026-09-15: implement the reportes RBAC resource in DEV. PROD preparation delegated for independent code and database comparison; no PROD write or deployment is authorized in this step.
-
DEV is already complete and verified live: resource reportes (id 24), module reportes (id 22), read grants to ADMIN/EDITOR/VIEWER/TRAMITES_PARQUE/VEHICULOS_VIEWER, and Elazar's ADMIN account has v_navbar_per_user.can_read=true. PROD comparison and deployment plan are delegated; no PROD write is authorized yet.
-
Applied in PROD under Elazar's fresh GO on 2026-09-15. Created reportes resource, reportes:read permission, module, and grants to ADMIN/EDITOR/VIEWER/TRAMITES_PARQUE/VEHICULOS_VIEWER. Independent post-check confirmed navbar reachability; no app deployment was needed.
-
coder03-mba-l-cc
-
Elazar, CLI 2026-09-18 (nqla 3a): se hace ahora. Su orden directa es el GO. coder03 escribe la migracion (DML de RBAC: resources + permissions + groups_permissions); la aplica un carril db - coder03 es SELECT only.
-
coder02-mba-l-cc
-
unassigned