Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Arthurr23/XHealtXperience/llms.txt

Use this file to discover all available pages before exploring further.

GET /dashboard is the main entry point for every authenticated user after login. Rather than rendering one generic page, DashboardController::index() inspects the authenticated user’s Spatie role and branches into a completely separate Inertia response — a different React component, and a different set of props — for each role. This keeps every persona’s workspace focused and avoids sending sensitive data (such as the full user list) to roles that don’t need it. All dashboard routes sit behind the auth + two_factor + check_inactivity middleware stack. The data each dashboard receives is assembled once in PHP before being serialized to the Inertia page props.

​
Role-to-Dashboard Mapping

RoleReact ComponentNotes
Super AdminDashboards/SuperAdminDashboardNo tenant context; manages clinic catalog at the central level.
Administrador Clinica / Administrador ProfesionistaDashboards/AdminDashboardFull clinic view: users, patients, agenda, services, surgeries.
DoctorDashboards/MedicoDashboardOwn agenda only; surgical view; no user management.
RecepcionDashboards/RecepcionDashboardScheduling-focused; patient intake; no surgery scheduling.
EnfermeroDashboards/EnfermeroDashboardSurgery schedule and patient list only.
PacienteDashboards/PacienteDashboardMinimal — tenant settings only.
AuditorDashboard (generic fallback)No dedicated branch in DashboardController; primary interface is GET /auditor/dashboard via AuditorController.

​
Props Delivered to Each Dashboard

The table below shows which Inertia props every role receives from DashboardController. A ✓ means the prop is included; — means it is not sent.
PropSuper AdminAdmin / Admin Prof.DoctorRecepcionEnfermeroPaciente
usuarios—✓————
pacientes—✓✓✓✓—
tenant_settings—✓✓✓✓✓
lineasServicio—✓————
servicios—✓✓✓——
citas—✓✓✓——
medicos—✓✓✓——
salas—✓✓✓——
fecha—✓✓✓——
bloqueos—✓✓✓——
cirugias—✓✓—✓—
quirofanosCatalogo—✓✓—✓—
procedimientosQuirurgicos—✓✓———
staffInterno—✓✓———
The Enfermero dashboard receives only pacientes, tenant_settings, cirugias, and quirofanosCatalogo. It does not receive procedimientosQuirurgicos or staffInterno — those are reserved for the Admin and Doctor dashboards where surgery scheduling is performed.

​
Per-Role Detail

​
Super Admin

The Super Admin dashboard receives no tenant-level data because it operates at the central database level — the tenancy is not initialized for this role. The React component fetches its own data (clinic list, global metrics) through the central application routes, not tenant routes.

​
Administrador Clinica / Administrador Profesionista

The Admin dashboard is the most data-rich view. It receives the complete data set:
  • usuarios — all users of the tenant with their Spatie roles, for the user management panel.
  • pacientes — all patient records ordered by apellido_paterno, used across the patient intake and search panels.
  • tenant_settings — security and notification settings (see the inactivity timeout note below).
  • lineasServicio — full service line catalog (active and inactive) for the services management panel.
  • servicios — full service catalog with lineaServicio, staffPerfiles, and etapas eager-loaded.
  • citas — appointments for the current and next month (active + completed), with patient, doctor, room, and service eager-loaded.
  • medicos — all users with the Doctor role, for scheduling dropdowns.
  • salas — all active rooms, for scheduling dropdowns.
  • fecha — today’s date string (Y-m-d), used to initialize the calendar view.
  • bloqueos — agenda blocks for the same date range as citas.
  • cirugias — surgical appointments for the current and next month with full team eager-loading.
  • quirofanosCatalogo — all rooms (all types, active and inactive), used for the OR management panel.
  • procedimientosQuirurgicos — full surgical procedure catalog.
  • staffInterno — users with Doctor, Enfermero, or Practicante Externo roles, for the surgical team builder.

​
Doctor

The Doctor dashboard mirrors the Admin view, minus:
  • No usuarios (user management is admin-only).
  • No lineasServicio (service line administration is admin-only).
Additionally, the citas and bloqueos queries are filtered to only return the authenticated doctor’s own appointments and blocks. The Doctor sees their personal agenda, not the full clinic schedule. 
// DashboardController — Doctor agenda filter
$citasQuery->when(
    $user->hasRole('Doctor') && ! $user->hasAnyRole(['Administrador Clinica', 'Administrador Profesionista']),
    fn ($q) => $q->where('medico_id', $user->id)
);

​
Recepcion

Reception receives everything needed to manage the front desk: patients, the full agenda (all doctors), room list, services, and agenda blocks. It does not receive:
  • usuarios — no user management.
  • lineasServicio — no service catalog administration.
  • cirugias, quirofanosCatalogo, procedimientosQuirurgicos, staffInterno — no surgical scheduling access.

​
Enfermero

The Nurse dashboard is focused on the operating room schedule:
  • pacientes — patient list for identification purposes.
  • tenant_settings — required for the inactivity timeout.
  • cirugias — upcoming and current surgical appointments with full team rosters.
  • quirofanosCatalogo — all room records (so the OR status grid can be rendered).
The Nurse cannot modify any records from the dashboard.

​
Paciente

Patient users receive only tenant_settings. The patient-facing dashboard is intentionally minimal — it is expected to be extended in future iterations with appointment history, document access, and messaging. No clinical data from other patients is ever sent to this role.

​
Auditor

The Auditor role has no dedicated branch in DashboardController::index(). An Auditor who visits GET /dashboard receives the generic Dashboard component (the safety-net fallback at the end of the controller). The Auditor’s primary interface is the dedicated route GET /auditor/dashboard (route name auditor.dashboard), served by AuditorController, which renders the full audit trail view. Auditors can also access the shared audit log at GET /bitacora (accessible to both Administrador Clinica and Auditor roles).

​
tenant_settings Prop Structure

The tenant_settings prop is assembled as a plain PHP array from the first TenantSetting record. It always includes these three keys: 
[
    'inactivity_timeout_minutes' => $s?->inactivity_timeout_minutes ?? 15,
    'max_login_attempts'         => $s?->max_login_attempts ?? 3,
    'visitor_checkin_token'      => $s?->visitor_checkin_token,
]
The inactivity_timeout_minutes setting controls the check_inactivity middleware that wraps all protected routes. If a user’s session has been idle for longer than this value (default: 15 minutes), the middleware forces a logout. Each clinic can configure its own timeout from the Admin Dashboard → Security Settings panel. The React frontend reads this value from tenant_settings and starts a client-side countdown to warn the user before the server-side kick.

​
Authentication Props via HandleInertiaRequests

The auth object (including the authenticated user’s name, ID, role, and role_name) is not included in the per-dashboard props above. It is shared globally for every Inertia response through HandleInertiaRequests::share(), so React components can always access usePage().props.auth without it being explicitly passed in each controller action.

Build docs developers (and LLMs) love

Get started for freeTalk to us