EduTrack Online — Frontend Build Order (Phase 1: SiteOwner)

Overview

Build these pages in order. Each page depends on the previous one.

Page 1: Login Page

APIs to use (from API_PUBLIC.md):

Flow:

1. User enters username + password → POST /accounts/login/
2. If 200 → store {role, name} in React state, redirect to Teachers Page (if role=siteowner)
3. If 401 → show error message
4. "Forgot Password?" link → step-by-step: email → OTP → new password

Required: Login form, Forgot Password modal/flow.

Page 2: Student Register Page (Public)

APIs to use (from API_PUBLIC.md):

Required fields in form:

• username (unique)
• password + password_confirm
• name_ar (Arabic name)
• name_en (English name)
• phone_number (Egyptian format: 010/011/012/015 + 8 digits)
• father_number, mother_number (parent phones)
• father_job
• educational_state → always "school" (hidden, hardcoded)
• school_type (select from dropdown)
• grade (select from dropdown)
• division (select from dropdown, filters by school_type + grade)
• school_name (text input)
• national_id (14 digits)
• birth_date (date picker)
• gender (male/female)
• gmail (unique across all users)
• facebook_link (optional)
• governorate (select from dropdown)
• area (select from dropdown, filters by governorate)

Dropdown data: Fetch from Settings endpoints (see Page 6).

Business rules:

• Division must belong to the selected school_type AND grade
• Area must belong to the selected governorate
• Student phone cannot match father's or mother's phone
• password_confirm must match password

Page 3: Teachers Page (SiteOwner Dashboard)

This is the main landing page after login. Shows all teachers as cards.

APIs to use (from API_SITEOWNER.md):

Teacher Card shows:

• Name
• Subject (from subject_detail.name)
• Grades (from grades_detail[].name)
• Course count (computed from teacher's courses — TBD, may need annotation)
• Active/Inactive status badge
• "View Courses" button → navigates to Teacher Courses Page
• "Edit" button → opens edit modal/inline form

Teacher List Filters:

• Search by name, phone, gmail, username
• Filter by is_active
• Pagination (default 50 per page, ?all=true for all)

Teacher Create Form fields:

• username, password
• name, phone, secondary_phone, gmail
• gender (male/female — required)
• subject (ID from subjects list)
• grades (array of grade IDs)
• is_active (checkbox, default true)
• biography, facebook (optional)

Success response: Returns full teacher profile with ID. Use this to navigate to the new teacher's detail.

Page 4: Teacher Detail Page (View/Edit Teacher)

Clicking on a teacher card or the edit button from the Teachers Page.

APIs to use:

Teacher Detail sections:

1. Profile Info — name, phone, gmail, subject, grades, active status. Editable.
2. Assistants List — read-only table showing assigned assistants (name, phone, gmail, is_active). Note: assistants are created later by the teacher themselves.
3. Create Course Button → opens a form to create a course for this teacher.

Course Create Form (inline):

• name (text — will be validated as unique per teacher+grade)
• grade (select from dropdown — teacher must teach this grade)
• description (textarea, optional)
• is_active (checkbox, default true)

Note: Subject is auto-derived from teacher.subject — NOT sent in request.

Success: After creating a course, the page should show a success message and optionally navigate to the Teacher Courses Page.

Page 5: Teacher Courses Page

List all courses for a specific teacher. Accessed via "View Courses" button on teacher card.

APIs to use:

Course Card shows:

• Course name
• Grade name
• Is Active badge
• Created date
• Topic count (from topic_count in response)
• Total lectures count (from total_lectures in response)
• "Edit" button → opens edit modal
• "Delete" button → only if course is empty (no enrollments)

Course Edit Form:

• name, description, is_active
• Cannot change: teacher, grade (these are locked after creation)

Course Delete rules:

• Can only delete if no enrolled students, no topics, no lectures, no materials
• DELETE returns 400 if students are enrolled
• Return a confirmation dialog before deleting

Page 6: Students Page (SiteOwner)

Manage all student registrations. Approve/decline pending students.

APIs to use:

Student List Filters:

• Search by name, student_code, phone, national_id, gmail
• Filter by status (verified/pending/declined/suspended)
• Filter by grade, school_type
• Sort by created_at, name, student_code
• Pagination (default 50)

Student Table columns:

• Student Code, Name (en), Grade, Phone, Gmail, Status badge, Created date, Actions

Student Detail view:

• Full profile info (name_ar, name_en, phone, father/mother numbers, school info, etc.)
• Status change buttons:
  • "Verify & Activate" → PATCH {status: "verified", is_active: true}
  • "Decline" → PATCH {status: "declined", is_active: false}
  • "Suspend (Temporary)" → PATCH {status: "suspended_temporary", is_active: false}
  • "Suspend (Permanent)" → PATCH {status: "suspended_permanent", is_active: false}

Default view: Show pending students first (sort by most recent).

Page 7: Settings Page (Read-Only Reference)

Display all reference data for preview. No CRUD operations.

APIs to use (from API_PUBLIC.md):

Note: All these endpoints support ?all=true to bypass pagination and get complete lists for dropdowns.

Static Files Needed

No static files are served by the backend. The frontend should handle all assets (images, icons, logos) on its own.

Auth Flow Summary

1. POST /accounts/login/ with {username, password}
2. Server sets httpOnly cookies: access_token (30min), refresh_token (7d)
3. Server returns JSON: {role: "siteowner", name: "Admin", is_active: true}
4. Frontend stores {role, name} in React context/state
5. All subsequent requests automatically send cookies (browser handles this)
6. When access_token expires → POST /accounts/token/refresh/ (reads refresh cookie)
7. POST /accounts/logout/ to clear cookies

Note: Since cookies are httpOnly, the frontend CANNOT read the JWT. Session restoration works via GET /accounts/me/ which reads the cookie and returns {role, name, is_active}.

Error Handling

All API errors follow this pattern:

{"error": "Human-readable error message"}

HTTP Status codes:

• 200 — Success
• 201 — Created
• 400 — Bad request (validation error)
• 401 — Not authenticated or invalid credentials
• 403 — Not authorized (wrong role)
• 404 — Not found
• 500 — Server error