# Phase 6: Student and Staff Management

## Completed work

- Atomic conversion of accepted applications into permanent student records.
- Collision-safe matriculation sequences based on institution, programme, admission
  year, and a zero-padded sequence.
- Student biographical, programme, campus, session, level, adviser, guardian,
  sponsor, ministry, welfare, graduation, and financial-status fields.
- Staff employment records, department/campus placement, next of kin, qualifications,
  authenticated accounts, and default Staff Member role assignment.
- Private student and staff document storage with MIME/size validation and hashes.
- Restricted medical/accommodation authorization and encrypted medical notes.
- Student and staff identity-card records with opaque public verification identifiers.
- Append-only student and staff status histories with mandatory reasons.
- Tenant-filtered, searchable, paginated administration interfaces.
- Student self-service read access to the student's own non-restricted record.
- Five demo lecturers and fifty demo students.

## Database changes

Migration `2026_07_30_130000_create_people_management_tables.php` adds:

- `student_number_sequences`
- `students`
- `student_guardians`
- `student_documents`
- `student_status_histories`
- `staff`
- `staff_qualifications`
- `staff_documents`
- `staff_status_histories`
- `identity_cards`

Tenant identifiers, institutional identifiers, user/application provenance, and
high-frequency status/programme/department lookups have database indexes and unique
constraints. Foreign keys restrict accidental deletion of permanent people records.

## Security controls

- Student and staff policies combine explicit permissions with tenant ownership.
- Students can view only their own records; self-service never exposes medical notes.
- Medical/accommodation documents require a separate restricted-data permission.
- Medical notes use Laravel encrypted casts and are not serialized by default.
- Files remain on a private disk and are served only after authorization.
- Applicant conversion, identity issuance, role replacement, copied document
  provenance, and initial history creation occur in one database transaction.
- Matriculation sequences are locked and also skip identifiers imported from legacy
  systems.

## Demo accounts

- `lecturer1@ecstu.test` through `lecturer5@ecstu.test`
- `student1@ecstu.test` through `student50@ecstu.test`
- Development-only password: `DevOnly!ChangeMe2026`

## Manual testing

1. Sign in as `admin@ecstu.test`.
2. Open Admissions, set an application to accepted, and select **Convert to student**.
3. Open Students to search, filter, edit a record, assign a guardian or level, upload
   a document, or record a reasoned status change.
4. Open Staff, create an employee, add qualifications/documents, and change status.
5. Sign in as `student1@ecstu.test` and open **My Record** to verify restricted
   welfare information and administrative controls are absent.

## Honest limitations

- Identity cards are persisted and display their verification ID, but styled card/PDF
  rendering and public QR verification belong to Phase 12.
- Attendance, discipline, chapel, internship, field ministry, and thesis-supervision
  workflows are assigned to their later academic/theological phases.
- Student financial status is readiness data only until Phase 11 supplies a verified
  ledger and clearance rules.
- Private S3 storage, malware scanning, retention automation, and expiring signed
  object URLs remain production-hardening work.

## Phase boundary

Phase 7 will add courses, versioned curricula, prerequisites, allocations, and course
registration. It has not been started.