Planned Not yet started — this page describes the intended design and build plan.
Overview
Today, Notipa's homework module is one-directional: a teacher posts an assignment with an optional due
date and attachment, and it appears for that class's guardians. There's no way to send anything back.
Homework submission closes that loop — a guardian (or, later, a student directly) attaches a file or
photo against a specific homework post, and the teacher sees it come in against a per-student roster,
the same way permission slip responses already work.
This isn't meant to become a learning-management system with rubrics, grading workflows, or plagiarism
checking. It stays deliberately small: a submission is a file plus a timestamp plus a status
(submitted / late / missing), attached to one student against one homework post.
How it will work
Teacher side. When posting homework, a teacher can toggle "accepts submissions" on. Once on, the homework detail view gains a per-student roster — identical in spirit to the existing permission-slip response list — showing submitted / late / missing for every student in the class.
Guardian side. On a homework post with submissions enabled, a guardian sees an upload control. They attach a file (image or PDF, size-capped) and optionally a short note, and can replace it any time before the due date passes.
Status logic. A submission's status is derived from the due date and submission timestamp — no manual bookkeeping required. Late submissions after the due date are still accepted and flagged, rather than blocked, since real households run late.
Notifications. A teacher can optionally get a read/submission digest, consistent with the existing read-tracking pattern on announcements, so they're not manually refreshing the roster.
Development plan
1Data model & backend
New HomeworkSubmission model: FK to Homework, FK to Student, file field, note, submitted-at timestamp, status.
Extend the Homework model with an accepts_submissions boolean.
Permission checks at the query layer so a guardian can only create/replace a submission for their own linked student(s), and can only see their own student's submission — never the whole class roster.
File storage: reuse the existing homework-attachment storage path/validation (type, size limits) rather than introducing a second file pipeline.
2Teacher & admin UI
Add the "accepts submissions" toggle to the homework create/edit form.
Build the per-student submission roster view on the homework detail page, mirroring the permission-slip response list component so the two features share styling and behavior.
Download/preview of a submitted file directly from the roster row.
3Guardian UI
Upload control on the homework detail view, shown only when accepts_submissions is true.
Submission state shown clearly (not submitted / submitted at [time] / late) with the ability to replace a file before the due date.
Handle the multi-guardian case: any guardian linked to the student can submit or replace, and all linked guardians see the current state.
4Testing & rollout
Unit tests for the permission boundary (a guardian cannot see or submit for a student they aren't linked to).
Manual QA across teacher and guardian demo accounts on app.notipa.org.
Migration is additive only — existing homework posts default to accepts_submissions = False, so nothing changes for schools already running Notipa until a teacher opts in.
Technical considerations
File size and type limits need to be conservative by default, since schools may be self-hosting on modest hardware and bandwidth.
No plagiarism detection, grading, or rubric scoring — that's out of scope, in keeping with Notipa staying a communication tool rather than a gradebook.
Role-based access is enforced at the data/query layer, consistent with how the rest of Notipa handles permissions — never just hidden in the UI.