​

SKOLE-WRIT — Write To (Parent Requests) Module

​

1. Overview

​

Scope In

• Parent: Create requests, view own requests by status, view thread with replies, reply to teacher response
• Teacher: View all incoming requests, assign to staff member, change status, add reply, resolve
• Request types: leave, complaint, general, query
• File attachment support (URL-based)

​

Scope Out

• Email/SMS notification on status change (planned)
• Escalation workflow to principal

​

2. Requirements

​

Functional Requirements (FR)

• SKOLE-WRIT-FR001: The module shall allow parents to create new requests with type (leave, complaint, general, query), subject, and message.
• SKOLE-WRIT-FR002: The module shall enable parents to view their own requests and filter them by status.
• SKOLE-WRIT-FR003: The module shall provide a threaded view for single requests, displaying all replies.
• SKOLE-WRIT-FR004: The module shall allow both parents and staff to add replies to an existing request thread.
• SKOLE-WRIT-FR005: The module shall enable teachers to view all incoming requests and assign them to specific staff members.
• SKOLE-WRIT-FR006: The module shall allow staff to update request statuses: pending, in-progress, resolved, or rejected.
• SKOLE-WRIT-FR007: The module shall capture resolution details (who resolved it, notes, and timestamp) when a request is marked as resolved.
• SKOLE-WRIT-FR008: The module shall allow for soft-deletion of requests and replies.

​

Non-Functional Requirements (NFR)

• SKOLE-WRIT-NFR001: The module shall behave securely by ensuring parents can only view requests they created (scoped by JWT parent_id).
• SKOLE-WRIT-NFR002: The module shall perform structured threading by strictly linking all replies to a parent write_to_id.
• SKOLE-WRIT-NFR003: The module shall behave reliably by tracking the is_read status of replies to ensure users are aware of new communications.
• SKOLE-WRIT-NFR004: The module shall perform secure data filtering by excluding all soft-deleted records from standard views.

​

Constraints

• C001: We must implement soft-deletion because the platform’s audit policy prevents permanent removal of communication records.
• C002: We must use the skole_id as the primary partition key for all request and reply lookups to maintain multi-tenancy.

​

3. Sub-modules / Backlog

​

4. Logical Implementation

​

Request Status State Machine

[pending] ──assign──→ [in-progress]
[in-progress] ──resolve──→ [resolved]  (captures resolved_by, resolution_notes, resolved_at)
[in-progress] ──reject──→ [rejected]
[pending|in-progress] ──delete──→ [deleted] (deleted_status=1)

​

Parent Create Flow

POST /parent-app/write-to
  ├─ Input: { skole_id, parent_id, student_id, request_type, subject, message,
  │           request_date, leave_from_date?, leave_to_date?, attachment_url?, priority }
  └─ INSERT write_to → return created request

​

Parent View Thread Flow

GET /parent-app/write-to/:id
  ├─ Verify request belongs to this parent (parent_id = jwt.sub)
  ├─ Fetch write_to record
  ├─ Fetch write_to_replies WHERE write_to_id = :id ORDER BY created_at ASC
  └─ Return { request, replies[] }

​

Teacher Reply Flow

POST /teachers-app/write-to/:id/reply
  ├─ Input: { replied_by, replied_by_id, message, attachment_url? }
  └─ INSERT write_to_replies + optionally update write_to.status

​

5. UI Requirements

​

Parent App — Write To Screens

• WriteToListScreen Loading: Skeleton cards
• Empty list: “No requests found. Tap + to create one.”
• WriteToDetailScreen Loading: Skeleton thread
• Error: Toast with retry

​

Teacher App — Write To

​

Web App

​

6. Conditional Expressions

​

7. Internal Module Connections

​

8. External Connections

​

9. Database Tables

​

write_to Key Columns

​

10. API Endpoints