Dashboard
One-line: the school admin’s landing screen — summary cards and charts that answer “how is my school doing right now?” at a glance.
What it does
When a school admin signs into admin-web, the dashboard is the first thing they see. It aggregates key numbers across modules — students, attendance, fees, staff — into summary cards and charts so an admin gets the state of the school without opening each module.
Who uses it
- School admins & sub-admins on the admin-web dashboard (the summary view).
- Teachers and students get their own role-appropriate home screens in the mobile app (today’s schedule, their attendance, their fees) rather than this admin dashboard.
Key concepts
- Summary cards — headline counts (e.g. total students, staff, today’s attendance rate, outstanding fees).
- Charts — trend/breakdown visualisations over the aggregated data.
- Role/branch scoping — a branch-restricted sub-admin sees figures for their allowed
school_units only (see Auth & RBAC).
How it works
The dashboard reads pre-aggregated summaries from the API rather than pulling raw lists. Aggregations are computed server-side (server/modules/dashboard/) and returned in one payload, so the screen loads with a small number of requests. Figures respect tenant scoping and the caller’s permissions/branch scope.
Rules & edge cases
- Tenant-scoped like everything else — a dashboard only ever reflects one school.
- Care is taken to avoid N+1 query patterns when computing summaries (a known reliability focus — see Roadmap, P2).
- What a user sees is filtered by their permissions and branch scope.
Where it lives
- Backend:
server/modules/dashboard/ - Admin-web: dashboard home under
admin-web/src/app/(dashboard)/ - Mobile: role-specific home screens in
client/