Planned Not yet started — this page describes the intended design and build plan.
Overview
Notipa is self-hosted specifically so a school's data belongs to the school, not a vendor. Data export
tools make that promise concrete at the feature level: an admin can export a school's own records —
students, guardians, announcements, homework, fee notices, permission slip responses, and (once built)
attendance and report cards — as CSV or PDF, on demand, without contacting anyone or filing a support
ticket.
This isn't a full backup/restore system (that's a database-level operation already covered by standard
Docker/Postgres backup practices) — it's a human-readable, portable copy of a school's records that an
admin can open in a spreadsheet or hand to another system.
How it will work
Per-record-type exports. An admin picks a record type (students, guardians, announcements, etc.) and an optional date range or class filter, and exports it as CSV for tabular data or PDF for anything meant to be read as a document (like a printed roster).
Scoped to the exporting admin's school. On a multi-school install, an export only ever contains that admin's own school's data, enforced the same way every other cross-school boundary in Notipa already is.
Background job for large exports. Bigger exports run as a background task rather than blocking the request, with the admin notified when the file is ready to download — so a large school's full-year export doesn't time out a web request.
No vendor lock-in, by design. This feature exists specifically so a school that decides to stop using Notipa can walk away with a complete, usable copy of its own data.
Development plan
1Export framework
A shared export utility (CSV writer + PDF renderer) that individual record-type exporters plug into, rather than one-off code per data type.
Permission checks reusing Notipa's existing school-scoping so an export can never cross a school boundary.
2Core record exports
CSV export for students, guardians, and the guardian-student linking table — the records a school is most likely to need for enrollment or reporting purposes outside Notipa.
CSV export for announcements, homework, fee notices, and permission slip responses, each with sensible default columns.
3PDF exports & background processing
PDF export for document-style output (e.g. a printable class roster, a permission-slip response summary) using a lightweight, dependency-light PDF library suited to a self-hosted footprint.
Move exports above a size threshold to a background task (reusing whatever async task runner the app already has, or a simple queue if none exists yet), with an in-app notification when the file's ready.
4UI & testing
Export panel in the admin dashboard listing available record types, filters, and format options.
Automated tests confirming exports never leak data across schools or beyond a role's normal visibility (e.g. a guardian never gets export tooling for records other than their own child's).
Manual QA opening exported CSVs and PDFs in common spreadsheet/PDF viewers to confirm formatting holds up.
Technical considerations
Kept deliberately separate from database backup/restore — this is an in-app, human-facing export, not the disaster-recovery story (which self-hosters handle at the Postgres/Docker level).
PDF generation library choice favors something lightweight, avoiding a heavy headless-browser dependency that would raise the resource bar for schools running on modest hardware.
Export scope automatically expands as new record types (attendance, report cards) are added, since it's built on the shared export framework from phase one rather than duplicated per feature.