Skip to content

Comisión: información restringida a Reportes y Dashboard de Supervisor

Date: 2026-07-25 Status: ✅ Aplicado en backend y frontend, verificado end-to-end (2026-07-27) — regla de negocio + seguridad, no fue solo un cambio visual Referencia funcional: doc/functional/2026-07-24-soterex-integracion-functional-analysis.md, sección 2.5 (nueva)

La regla

El monto de comisión CIS de una transacción no se muestra en ningún lugar operativo — ni listado ni detalle de Transacciones, ni en el modal de confirmación de pago/cancelación. Se muestra únicamente en:

  1. Reportes (estado de situación contable, agregados).
  2. Dashboard, solo para el rol Supervisor — no para Backoffice ni ningún otro rol.

Por qué esto no se resuelve solo en el frontend

Si el backend sigue devolviendo el campo fee/comision en la respuesta de la API sin importar quién pregunta, alcanza con abrir las DevTools del navegador (pestaña Network) para verlo — ocultar la columna en la tabla no protege nada. La restricción real tiene que estar en el backend, condicionando qué campos incluye cada respuesta según el rol de quien hace el request.

Qué cambiar

Backend (lo más importante)

  • [x] GET /api/transacciones — no incluye fee en la respuesta.
  • [x] GET /api/transacciones/{id} (detalle) — mismo criterio.
  • [ ] Los endpoints que alimentan Reportes y el Dashboard de Supervisor sí incluyen el campo, sin cambios. No aplica todavía — M3 (Dashboard/Reportes reales) no existe, son pantallas placeholder. Ver "Decisión de implementación" abajo.
  • [x] Revisado: no hay endpoint de auditoría real todavía (M4 pendiente), y el AuditLog que ya graba pay/cancel (metadata: ['from', 'to', 'mtcn']) nunca guardó fee — nada que corregir ahí.
  • [x] Encontrado en el camino, no estaba en el checklist original: el 422 de saldo insuficiente devolvía required (amount+fee) — como amount ya es público, restar permitía derivar la comisión exacta. Sacado; queda solo balance.
  • [x] Encontrado en el camino: la whitelist de sort todavía aceptaba comision — sacada (ya no hay columna que la use, y ordenar por un valor no expuesto es en sí mismo un canal indirecto de exposición).

Decisión de implementación (a confirmar si no es la lectura correcta): en vez de construir la condición de rol/contexto para Reportes/Dashboard ya mismo, se creó TransactionResource (app/Http/Resources/TransactionResource.php) que hoy excluye fee siempre, sin excepción, porque hoy no existe ningún consumidor real de Reportes/Dashboard — M3 sigue siendo placeholder. Construir ahora la lógica condicional (¿un query param? ¿un header? ¿reusar este mismo endpoint o uno nuevo?) sería adivinar una forma que M3 todavía no definió. El Resource queda como el punto de extensión correcto — cuando M3 se implemente de verdad, ahí se agrega la condición de rol/contexto sobre este mismo archivo (o se decide un endpoint separado para Reportes/Dashboard, lo que tenga más sentido en ese momento).

Nota de implementación: si GET /api/transacciones es un único endpoint reusado tanto para el listado operativo de Backoffice como para alimentar el Dashboard/Reportes de Supervisor, la forma más limpia de resolver esto es que el Resource/Transformer de Laravel decida incluir o no el campo fee según $request->user() y el rol/contexto — no armar dos endpoints separados si no hace falta.

Frontend (ya resuelto en los archivos de referencia — aplicar el mismo patrón sobre el código real)

  • [x] TransaccionesView.vue — columna "Comisión" sacada del listado operativo (y de la whitelist de sort del backend).
  • [x] TransaccionDetalleView.vue — dato de comisión sacado de "Datos de la transacción" y de los dos <ConfirmActionModal> (pay/cancel). También se actualizó el mensaje de saldo insuficiente (ya no depende de required, ver nota del backend).
  • [x] ConfirmActionModal.vue — prop comision y fila del recibo sacados (real, no solo la referencia).
  • [ ] ReportesView.vue y el Dashboard (cuando se implementen de verdad en M3): sí deben mostrar comisión — este módulo no se toca, es donde el dato debe aparecer.
  • [ ] Dashboard: cuando se implemente de verdad, cualquier KPI que incluya comisión debe estar condicionado a role === 'Supervisor' (o el mecanismo de permisos que ya exista) — un Backoffice que entra al Dashboard no debe ver esos KPIs, aunque sí vea otros.

Verificado con la respuesta real de la API (Network, no solo el DOM): ni GET /api/transacciones ni GET /api/transacciones/{id} incluyen la key fee en ningún ítem — comprobado interceptando las respuestas reales con Playwright, no asumido desde el frontend. 6 tests nuevos en TransactionApiTest.php (53 en total): index/show/pay/cancel sin fee, sort por comisión rechazado, y saldo insuficiente sin required.

Qué NO cambia (a confirmar con el cliente)

ABM Países (donde Admin configura el % de comisión editable por país) sigue visible/editable para el rol Admin sin cambios — se interpreta que esto es configuración del sistema, distinto de "mostrar la comisión de una transacción puntual". Confirmar con el cliente si esta lectura es correcta o si también hay que restringir esa pantalla de alguna forma.

Archivo de referencia adjunto

reference/ConfirmActionModal.vue — versión corregida, sin el prop ni la fila de comisión.

Documentación viva — se actualiza junto con el código, no es un anexo aparte.