Term-by-term academic reports, generated per student and delivered straight to their guardians through Notipa — no separate spreadsheet or paper slip to lose.
Planned Not yet started — this page describes the intended design and build plan.
Overview
Notipa currently has no gradebook and isn't becoming one. Report cards are the one piece of academic
reporting that fits the project's scope anyway: a teacher (or admin, on a teacher's behalf) records a
small, structured summary per student per term — subject grades or marks, an attendance summary line,
and a free-text comment — and it's published to that student's guardians the same way an announcement
is, with read tracking.
The goal is to replace the "photocopied slip sent home in a backpack" step, not to build a full academic
records system with weighted assessments, standards tracking, or transcript generation. Each report is a
single, dated document tied to one student and one term.
How it will work
Term setup. An admin defines the school's terms (e.g. Term 1, Term 2, Term 3) once per year. This also lays groundwork the calendar feature will build on.
Report entry. A teacher fills a per-student report form for their class: a configurable set of subject/grade rows, an optional narrative comment, and an attendance summary pulled in automatically once attendance tracking exists.
Draft/publish. Reports follow the same draft-then-publish pattern as announcements — a teacher can save incomplete work and only guardians see it once published, so nothing half-written reaches a family.
Guardian view. A guardian sees a simple, printable report view for each of their linked students, with a history across past terms.
Development plan
1Terms & data model
New Term model scoped per school (name, start date, end date), managed by admins.
New ReportCard model: FK to Student, FK to Term, status (draft/published), comment field, published-at timestamp.
New ReportCardEntry model for subject rows: FK to ReportCard, subject name, grade/mark value — kept as free text or a simple scale rather than a rigid schema, so it fits different schools' grading conventions.
2Teacher & admin UI
Term management screen for admins.
Report entry form for teachers, scoped to their own class(es), with the ability to duplicate the subject list across students in a class to speed up entry.
Bulk "publish all drafts for this term" action, since a teacher will typically finish a whole class at once.
3Guardian UI & delivery
Report card view on a student's profile, showing published reports by term, newest first.
Print-friendly layout (clean CSS print stylesheet, no app chrome) so a guardian can save or print a copy.
Notification when a new report is published, reusing the existing announcement notification path.
4Testing & rollout
Permission tests: a teacher can only enter reports for students in their own class; a guardian can only see their own linked students' reports.
QA with multi-guardian households to confirm all linked guardians see the same published report.
Backward-compatible migration — schools not using the feature simply have no terms defined and see nothing new.
Technical considerations
Grading scale stays flexible (free text per subject row) rather than hard-coded, since schools vary widely — letter grades, percentages, or descriptive marks all need to fit.
Print output is plain CSS, not a PDF generation dependency, to keep the self-hosted footprint light.
No weighted GPA calculation or transcript export in this phase — that's a natural future extension once the basic report exists.