# FAPI — Phase 2 Deferred Features

Items intentionally excluded from Phase 1 and reserved for Phase 2 implementation.

---

## ~~1. File Upload for Question Responses~~ ✅ Implemented

**Status:** Completed

Fully implemented in Phase 1. Key deliverables:
- **Backend:** `UploadService` with S3 integration via `ResourceService` — `getUploadContext()`, `registerFiles()`, `getFileInfo()`, `deleteFile()`
- **Database:** Migration `20260514100016` renamed `file_path` → `lin_resource_id` on `fapi_question_response`
- **Frontend:** `FileUpload.vue` (FilePond-based S3 upload component) and `FileThumbnail.vue` in `modules/common/src/components/`
- **Validation:** Hard validation on submit requires `lin_resource_id` when `has_file_upload = true`
- **Types:** `UploadContext`, `S3PendingFile`, `FileInfo` interfaces in `submission.ts`

---

## 2. Export (Print & Excel)

**Architecture reference:** Section 6.1 — Summary report (*"Export: Print and Excel"*), Section 6.2 — Detailed view (*"Export: Print"*)

**What exists in Phase 1:**
- `GET /v1/report/summary` — returns JSON data
- `GET /v1/report/faculty/{enrollmentId}` — returns JSON data

**What is missing:**
- Excel export for summary report
- Print-ready export for summary report and detailed faculty view

**Phase 2 scope:**
- Add `?export=excel` query param to `GET /v1/report/summary` → generates and returns `.xlsx` file
- Add `?export=print` to both report endpoints → returns a print-optimised HTML or PDF response
- Library to consider: PhpSpreadsheet for Excel generation

---

## 3. Admin Bulk Faculty Assignment with Filters - Already Implemented

**Architecture reference:** Section 2.5 — Faculty assignment

> "Faculties are assigned to applications with filtering options: Department (multi-select with select all), Teaching or non-teaching, Guest or permanent, Individual faculty selection (multi-select with select all). New faculty can be added to a published application at any time."

**What exists in Phase 1:**
- Faculty self-enrollment only (`POST /v1/enrollment`)
- `fapi_faculty_enrollment` table supports the same data model

**What is missing:**
- Admin-side bulk assignment endpoint with department, teaching type, and employment type filters
- Ability for admin to add individual faculty to an already-published application
- Endpoint to remove a faculty from an application (before any tier is submitted)

**Phase 2 scope:**
- `POST /v1/enrollment/bulk` — admin assigns faculty using filter criteria. Body: `{ appId, deptIds[], teachingType, employmentType, staffIds[] }`
- On bulk assign: same enrollment + tier submission creation logic as self-enroll, run per faculty in a transaction
- `DELETE /v1/enrollment/{id}` — admin removes enrollment (only allowed if tier 1 status = `not_started`)
- Enforce that faculty cannot self-enroll into an application where admin assignment is the intended mode (controlled via `fapi_application.properties`)

---

## 4. Application Eligibility Criteria (properties JSON)

**Architecture reference:** Section 2.2 — Application layer, DB design section 3.2

> "The `properties` JSON column is reserved for phase 2 eligibility criteria (department filters, teaching/non-teaching, guest/permanent). For now, all published applications are visible to all faculty."

**What exists in Phase 1:**
- `properties LONGTEXT COMMENT 'JSON'` column on `fapi_application`
- Stored and returned as-is; no logic reads it

**What is missing:**
- Eligibility filter enforcement in `getAvailableApplications()` — currently returns all published in-window applications to all faculty
- Admin UI for configuring eligibility criteria per application

**Phase 2 scope:**

Define a `properties` JSON structure, for example:
```json
{
  "eligibility": {
    "deptIds": [1, 2, 3],
    "teachingType": "teaching",
    "employmentType": "permanent"
  }
}
```

Update `getAvailableApplications()` to filter based on the faculty's profile:
- If `eligibility.deptIds` is set → only show to faculty in those departments
- If `eligibility.teachingType` is set → filter by teaching/non-teaching
- If `eligibility.employmentType` is set → filter by guest/permanent
- Empty or missing `eligibility` → visible to all faculty (current Phase 1 behaviour)

---

## 5. Results Publication

**Architecture reference:** Section 7 — Access control summary

> Admin can: *"Publish apps and results."*

**What exists in Phase 1:**
- `togglePublish` on `fapi_application` controls application visibility to faculty
- No mechanism to publish final appraisal scores to faculty

**What is missing:**
- A results publication flag or endpoint so faculty can view their own appraisal scores after the admin releases them
- Faculty-facing result view: their own section totals and overall totals per tier (read-only, post-publication)

**Phase 2 scope:**
- Add `is_results_published TINYINT(1) DEFAULT 0` column to `fapi_application`
- `PUT /v1/application/{id}/publish-results` — admin toggles result visibility
- `GET /v1/enrollment/{id}/results` — faculty endpoint; only accessible when `is_results_published = 1` and enrollment status = `completed`; returns aggregated section totals per tier (read-only)