# School MIS — Student admissions (Django + React)

Workplan to replace the **CodeIgniter online admissions** flow with a **Django + React** implementation, reusing **Grading** app styling (`App.css`, branding, patterns) and keeping the existing **examination / grading** module as-is.

## 1. Legacy system (reference)

| Item | Location |
|------|----------|
| **Web root (document root)** | `/Users/macbook/Documents/school` — the folder that contains **`index.php`**. Point Apache/Nginx `DocumentRoot` (or PHP built-in server) here. CodeIgniter 3 front controller is **`index.php`** at this level. |
| **Application code** | `application/` — controllers, models, views. |
| **Online admissions (admin)** | `application/controllers/admin/Onlineadmission.php` — settings, form fields, applicant handling. |
| **Model / data** | `application/models/Onlinestudent_model.php` — table **`online_admissions`**, joins to classes, sections, transport, hostel, categories, etc. |
| **Public forms & payments** | `application/controllers/onlineadmission/*.php` — Stripe, Paystack, M-Pesa-style gateways (large surface; **phase later**). |

**Implication:** Full parity with the PHP app on day one is not required. We implement a **lean admissions pipeline** first, then extend (custom fields, payments, transport/hostel) as needed.

---

## 2. Target architecture

- **Django:** New apps (or namespaces) for `admissions` — REST API, models, permissions, file uploads.
- **React (Vite):** New routes/sections under the same shell as Grading (shared toolbar, `BRANDING`, CSS variables).
- **Grading:** Unchanged for marks/reports; **Students** in Grading may later **sync** from admitted learners or stay separate until integration is defined.

---

## 3. Phases

### Phase A — Foundation (before UI)

1. **Single-school vs multi-school**  
   Align with Grading’s `School` model: admissions belong to a `school_id`.

2. **Admission intake model (MVP)**  
   Fields aligned to your process, inspired by legacy `online_admissions` but trimmed:
   - Reference / application id (auto)
   - Applicant: name, DOB, gender, contact, address (as needed)
   - Intended entry: academic year, **target class / form** (map to your streams later)
   - Status: `draft` → `submitted` → `under_review` → `accepted` | `rejected` | `waitlisted`
   - Timestamps, optional notes (internal)
   - Optional link: “promote to **Student**” when accepted (creates or links `grading.Student`)

3. **API**  
   DRF: list/create/update for staff; optional public `POST` for application submit if you want a public form later.

4. **Auth / roles**  
   Reuse or extend Grading auth: staff-only for review; public endpoints gated or disabled until Phase C.

### Phase B — Staff UI (first deliverable)

1. **React: “Admissions” area**  
   - List with filters (status, year, class intent)  
   - Detail drawer/page: view/edit status, notes  
   - Actions: Accept / Reject / Waitlist (with confirm)  
   - Empty states and errors consistent with Grading

2. **Styling**  
   Reuse `app-toolbar` patterns, cards, tables, primary/secondary buttons, same typography.

3. **Exports (optional MVP+)**  
   CSV export of applications for the office.

### Phase C — Applicant-facing (optional)

1. Public or logged-out **application form** (multi-step if long).  
2. **File uploads** (birth certificate, etc.) — S3/local storage, virus scan policy TBD.  
3. **Email notifications** — submitted / decision (Django email or provider).

### Phase D — Parity with CodeIgniter (as needed)

1. **Custom fields** — configurable JSON or EAV; mirror `getformfields()` behaviour only if required.  
2. **Online payment** for application fee — pick one gateway (e.g. M-Pesa or Stripe) and scope tightly.  
3. **Transport / hostel / class-section** pickers — only if your school uses them in admissions.

### Phase E — Integration

1. **Accepted applicant → Enrolment**  
   Create `ClassEnrollment` + `TermReport` shell in Grading, or a dedicated “Enrol student” action from admission record.  
2. **Data migration** (optional): one-off script from MySQL `online_admissions` export to Django.

---

## 4. Implementation order (concrete)

| Step | Task |
|------|------|
| 1 | Add Django app `admissions` with models + migrations + admin (quick sanity check). |
| 2 | DRF serializers/viewsets + permissions (`IsAuthenticated`, school scoping). |
| 3 | React: route `Admissions` in shell, list + detail + status actions. |
| 4 | Wire API base URL / CSRF if same origin; env `VITE_API_URL`. |
| 5 | Manual QA; adjust fields with your registrar. |
| 6 | (Later) Public form + uploads + payments per phases C–D. |

---

## 5. Risks & decisions

- **Scope:** Legacy admissions touches **payments, transport, hostel, many custom fields**. MVP avoids most of that.  
- **Duplicate students:** Rules needed for matching NEMIS/admission no. vs existing `Student`.  
- **Single repo:** Keep everything in the Grading monorepo unless you prefer a separate service.

---

## 6. Next action

Approve **Phase A + B (MVP staff admissions)**. Then implementation starts with Django models + API + React list/detail in the existing project layout.