A shared thread for a class's teacher and its guardians — the "class WhatsApp group," but inside Notipa, moderated by the teacher, and scoped only to that class.
Planned Not yet started — this page describes the intended design and build plan.
Overview
Many classes end up with an unofficial parent group chat somewhere else — WhatsApp, Facebook, Viber —
that the school doesn't control and can't moderate, and that a new family isn't automatically part of.
Class group messaging brings that shared space inside Notipa instead: one thread per class, automatically
including the class's teacher and every guardian linked to a student in that class.
One thread per class. Created automatically the first time a school's messaging setting is turned on for a class with at least one enrolled student, and kept in sync as students join or leave the class.
Teacher-moderated. The teacher can post and, if needed, remove a message — Notipa doesn't attempt automated content moderation, so the teacher stays the backstop, consistent with how a real classroom group works.
Guardian participation. Guardians can post into the shared thread by default, with a per-class setting a teacher can flip to "announcements only" (teacher posts, guardians read) if a class's dynamics call for it.
Automatic membership. A guardian is added the moment their child is enrolled in the class, and removed if the child leaves — no manual invite step for either side.
Development plan
1Schema extension
Extend the guardian↔teacher messaging thread model to support a class-scoped thread type alongside the existing one-to-one type, with a many-to-many participants relation instead of two fixed FKs.
Signal/hook on class enrollment changes to keep thread membership in sync automatically.
2Moderation controls
Teacher-only "remove message" action, with the removed message left as a visible placeholder rather than silently vanishing, so context isn't lost mid-thread.
Per-class "announcements only" toggle restricting posting to the teacher.
3UI
Class thread accessible from the class page for teachers and from each linked student's class for guardians.
Participant list visible so guardians can see who else is in the thread — transparency instead of an anonymous crowd.
Unread badge consistent with the guardian↔teacher messaging inbox, so both message types surface in one place.
4Testing & rollout
Test enrollment-change edge cases: a mid-term transfer should add/remove thread access immediately, not leave stale access behind.
Confirm the messaging toggle in the per-school switch disables class threads the same way it disables one-to-one threads.
Scale check on notification volume — a 30-guardian class thread shouldn't flood every participant on every message; batching or a digest option may be needed.
Technical considerations
Built directly on top of the guardian↔teacher messaging schema rather than as a separate system, to avoid maintaining two parallel messaging models.
Notification volume is the main open design question — likely a digest/mute option per thread rather than a push per message, once usage data exists.
No file attachments or read receipts in the first version, matching the scope decision made for one-to-one messaging.