Navegacion

Matriz de permisos

Esta pagina resume los permisos principales de Lexa por rol y modulo. Esta basada en atributos de autorizacion observados en Razor Pages, policies multi-tenant y filtros globales.

No reemplaza pruebas de autorizacion ni revision de reglas internas por servicio.

Roles

Rol Descripcion
SUPER_ADMIN Administracion global de la plataforma.
ADMIN Administrador de una empresa/tenant.
THERAPIST Profesional/terapeuta de una empresa.
SECRETARY Secretaria/recepcion de una empresa.
COORDINATOR Coordinador con scope operacional especifico.
PATIENT Portal de paciente.

Controles transversales

Control Descripcion
Autenticacion La mayoria de pantallas internas exige login.
Company context Filtros globales exigen empresa activa cuando corresponde.
Onboarding Filtro global puede redirigir si la empresa no completo onboarding.
Claims tenant TenantContextMiddleware extrae company, identity, roles y rol activo.
Policies Existen policies para super admin, company context y roles de empresa.

Matriz por modulo

Modulo SUPER_ADMIN ADMIN SECRETARY THERAPIST COORDINATOR PATIENT Notas
SuperAdmin Si No No No No No Usa RequireSuperAdmin.
Dashboard owner No directo Si No No No No Ruta principal de admin.
Dashboard recepcion No directo Si Si No No No Usado por admin/secretaria.
Dashboard terapeuta No directo No No Si Parcial No Coordinator puede redirigir a vista terapeuta segun contexto.
Portal paciente No No No No No Si Usa RequireCompanyRole(PATIENT).
Empresas globales Si No No No No No Admin global de companies/billing.
Usuarios empresa No directo Si No No No No RequireCompanyAdmin.
Roles usuarios No directo Si No No No No Incluye restricciones de paciente vs staff.
Configuracion empresa No directo Si No No No No Settings, billing, templates y parametros.
Sucursales No directo Si Parcial No No No Listado/schedule admin/secretaria; crear/editar/borrar admin.
Servicios No directo Si Parcial No No No Listado admin/secretaria; crear/editar/borrar admin.
Agendas online No directo Si No No No No Admin.
Feriados No directo Si Si No No No Admin/secretaria.
Convenios/agreement No directo Si Si No No No Admin/secretaria.
Becas No directo Si No No No No Admin.
Planes de atencion No directo Si Parcial No No No Listado/activos admin/secretaria; CRUD admin.
Pacientes listado No directo Si Si Si No directo No Admin,Secretary,Therapist.
Pacientes crear/editar No directo Si Si No No No Crear/editar restringido a admin/secretaria.
Ficha clinica No directo Autenticado Autenticado Autenticado Autenticado No Tiene [Authorize]; revisar reglas internas de servicio.
Agenda/citas No directo Si Si Si Posible parcial No Varias paginas usan [Authorize]; acciones pueden depender de servicio.
Conflictos agenda No directo Si Si No No No Admin/secretaria.
Terapeutas listado No directo Si Si No No No Admin/secretaria.
Terapeutas CRUD No directo Si No No No No Admin.
Mis citas terapeuta No directo No No Si No No Therapist.
Mis pacientes terapeuta No directo No No Si No No Therapist.
Comisiones terapeutas No directo Si No No No No Admin.
Caja No directo Si Si No No No Admin/secretaria.
Ventas No directo Autenticado Autenticado Autenticado Autenticado No Requiere revision de reglas internas.
Facturas/boletas No directo Si Si No No No Admin/secretaria.
Gastos No directo Si Si No No No Admin/secretaria.
Reportes financieros No directo Si No No No No P&L, historia, bancos, comisiones, becas.
Reportes operacionales No directo Si Parcial No Parcial No Algunos reportes admin/secretaria; productividad admin/coordinator.
Waitlist No directo Si Si No No No Admin/secretaria.
Mural No directo Si Si Si Si No Staff y coordinator.
Tareas secretaria No directo Si Parcial No No No Admin crea/ve todo/reabre/elimina; secretaria toma/cambia estado solo en su sucursal + globales (F058).
Coordinator pacientes No directo No No No Si No Coordinator.
Coordinator pendientes No directo Si No No Si No Admin/coordinator.
Onboarding No directo Si No No No No Admin.
Suscripcion/convertir No directo Si No No No No Admin.
UI kit interno No directo Si No No No No Admin.

Endpoints y paginas anonimas

Area Acceso Notas
Login/reset/forgot password Anonimo Flujo de cuenta.
Trial/signup/verificacion Anonimo Creacion/verificacion trial.
Booking publico Anonimo Reserva publica.
Check-in Anonimo Debe validarse por token/contexto.
Encuesta Anonimo Debe evitar datos sensibles en URL.
Intake form Anonimo Debe validarse por token/contexto.
Blog/wiki/sitemap/feed Anonimo Contenido publico/SEO.
Webhooks pagos Anonimo Validacion por proveedor e idempotencia.
Webhook WhatsApp Anonimo Verify token en GET; procesamiento defensivo en POST.
ACS email events Anonimo Debe validar secret/handshake.
Acciones email cita Anonimo GUID publico, noindex y reglas de elegibilidad.
api/version Anonimo Operacion post-deploy; no exponer secretos.
api/public-blob Anonimo limitado Solo therapists/ y company-logos/.
api/blob Autenticado Proxy privado.

Reglas especiales observadas

Paciente vs staff

Servicios de usuarios restringen combinaciones de roles:

  • PATIENT no debe mezclarse con roles staff.
  • Staff no debe mezclarse con PATIENT.
  • Al crear staff se generan/validan entidades asociadas segun rol.

Coordinator

COORDINATOR tiene tratamiento especial:

  • Puede acceder a paginas coordinator.
  • Puede aparecer en flujos tipo terapeuta segun contexto.
  • Requiere scope/resolucion adicional para pacientes asignados.

Company context

Aunque una pagina tenga [Authorize] simple, los filtros globales y middleware pueden exigir contexto de empresa. Por eso la matriz distingue entre acceso por atributo y reglas internas.

Riesgos a validar con pruebas

Riesgo Prueba recomendada
Usuario de empresa A ve datos de empresa B Fixtures multi-company con casos negativos.
Terapeuta accede a paciente no asignado Tests de ficha, agenda y reportes por terapeuta.
Secretaria accede a configuracion admin Tests sobre paginas admin sensibles.
Coordinator excede su scope Tests de pacientes asignados/no asignados.
Paciente accede a rutas staff Tests de rutas internas con rol PATIENT.
Endpoint [Authorize] sin policy filtra datos Tests por handler/servicio con company context.
Blob privado expone documentos Tests de prefijos sensibles y company mismatch.
Webhook duplica pagos/cambios Tests de idempotencia por proveedor.

Checklist para nuevas paginas

  1. Definir rol minimo antes de implementar.
  2. Usar policy/attribute explicito cuando sea posible.
  3. Confirmar que toda query sensible filtra por CompanyId.
  4. Validar que servicios no dependan solo de ocultar botones en UI.
  5. Agregar prueba negativa para roles no autorizados si la accion toca pacientes, pagos, DTE o configuracion.
  6. Revisar si la pagina necesita aparecer en menus por rol.
  7. Documentar excepciones anonimas con razon y control compensatorio.

Pendientes recomendados

  • Crear una suite automatizada de autorizacion multi-tenant.
  • Generar inventario completo ruta por ruta desde Razor Pages.
  • Documentar matriz de menus visibles por rol.
  • Revisar paginas con [Authorize] generico y moverlas a policies explicitas cuando corresponda.
  • Agregar tests de endpoints anonimos con payloads duplicados o invalidos.