02 — User Personas (Files Module)

• 1. Admin / Super Admin (web-first)
• 2. Office Manager / Exam Cell (web)
• 3. Teacher (web + mobile companion)
• 4. Student / Parent (mobile companion, forward-looking)
• 5. API / Integration Consumer (webhooks, scripts)
• Persona → permission matrix

Personas are derived from the RBAC permission set and the module's endpoint surface (permissions.constants.ts:86-88, files.controller.ts:29-71). Platform-wide persona notes live in 00-shared/01_Product_Overview; this file only adds the file-handling dimension.

1. Admin / Super Admin (web-first)

• Grants: file.read, file.upload, file.delete (via role assignment).
• Jobs: upload fee circulars, student TC documents, school logos; delete misplaced or sensitive uploads; audit what is stored.
• File behaviour: expects a flat list sorted newest-first (GET /files, sorted createdAt: -1, files.service.ts:48-50); downloads via attachment (browser save dialog, files.controller.ts:61); deletes with a confirm step because deletion is permanent at storage layer (files.service.ts:68-69).
• Pain points: no search/pagination today — list is all-or-nothing.

2. Office Manager / Exam Cell (web)

• Grants: file.upload, file.read (delete often withheld).
• Jobs: bulk-attach marksheets and certificates to records; re-upload corrected copies.
• File behaviour: uploads one file at a time (multipart file field only, files.controller.ts:31); needs clear success/id of returned record (files.service.ts:36-45); cannot rename or replace — must delete + re-upload (no file.update permission exists).
• Pain points: no multi-file upload; large scans held fully in server memory (FileInterceptor buffer → provider buffer → res.send, files.controller.ts:57-63).

3. Teacher (web + mobile companion)

• Grants: file.upload, file.read.
• Jobs: attach homework PDFs, class-photo albums, result PDFs to their context screen.
• File behaviour: uploads from the module screen that owns the record (files are context-agnostic server-side — the record is a plain document with no folder field; file.schema.ts:9-25); downloads what students were supposed to submit.
• Pain points: no per-context listing server-side; client must filter by its own metadata.

4. Student / Parent (mobile companion, forward-looking)

• Grants: file.read only (download/verify; no upload, no delete).
• File behaviour: expects tap-to-download with progress, open in system viewer, no storage URL visible. Authentication on download is the same RBAC file.read (files.controller.ts:56) — works on any client.
• Pain points: buffered download means big PDFs look "stuck"; progress bar must come from the client transport (see 15_Flutter_Implementation_Guide.md).

5. API / Integration Consumer (webhooks, scripts)

• Grants: whatever the service token holds; typically file.upload + file.read.
• File behaviour: POSTs multipart/form-data with field name file (files.controller.ts:31-37), parses the returned FileRecord JSON, later pulls GET /:id/download (Content-Type echoed from stored mimeType, files.controller.ts:60).
• Pain points: no signed-URL flow wired into the service (provider getSignedUrl exists, storage-provider.ts:25, but FilesService never calls it) — (planned).

Persona → permission matrix