02 — User Personas (Notifications Module)

• P1 — Student (School & Coaching)
• P2 — Teacher
• P3 — Parent
• P4 — Org Admin / School Admin
• P5 — Platform Admin (Super Tenant)
• Permission Matrix

Derived from source only. Personas are the five identity classes present in StudyLyon (permissions.constants.ts + RBAC member model). Notification content today is account-lifecycle only; domain payloads (homework, results, fees) arrive via the event pipeline — see gaps in 14_QA_Checklist and 01_Product_Overview §3.

P1 — Student (School & Coaching)

• Profile: enrolled pupil; coaching variant tracked per docs/IMPLEMENTATION_PLAN.md:769 (test reminders, DPP due alerts, batch start, rank updates — (forward-looking)).
• Today receives: welcome (UserRegistered), email-verified, verification resent, password reset — notifications.handler.ts:8-50.
• Needs: glanceable unread badge, newest-first list, one-tap mark read.
• Pain points: buried system emails; notification fatigue if every school event pings the inbox (see 09_User_Behaviour).

P2 — Teacher

• Profile: staff member with teaching duties; homework-graded / attendance events route to the in-app queue per event-queue-map.ts:14-25 (planned).
• Needs: distinguish actionable items (grade homework, results published) from informational ones; bulk "mark all read" after a teaching block.
• Today: same four account events as P1.

P3 — Parent

• Profile: account linked to a student; reads announcements and fee invoices. Invoice events exist (event-queue-map.ts:41-42 → emails queue).
• Needs: unread count on the dashboard shell; parent is a viewer — no send capabilities (notification.update is not in parent's default set).

P4 — Org Admin / School Admin

• Profile: tenant administrator; manages users, fees, announcements.
• Needs: assurance that system events surfaced to the right recipients; (planned) manual send to a target audience via POST /api/v1/notifications/send (Notifications.md:24) and channel-preferences management (Notifications.md:27-28).
• Permissions: notification.read, notification.update (permissions.constants.ts:32-33).

P5 — Platform Admin (Super Tenant)

• Profile: StudyLyon operator; cross-tenant oversight.
• Needs: DLQ/retry visibility for the notification pipeline (Notifications.md:41 — NotificationFailed event, (planned)).

Permission Matrix

All read actions are owner-scoped by the service: markAsRead returns null when recipientId !== userId (notifications.service.ts:54-59).