A school or individual teacher can turn guardian ↔ teacher and class group messaging off entirely if they're not ready to support it — messaging should be a choice, not a default a school gets stuck with.
Direct messaging is a real operational commitment for a school: someone has to be expected to actually
read and respond to it, and a school that isn't staffed or ready for that shouldn't be forced into it
just because the feature exists in the software. This switch makes messaging strictly opt-in, at two
levels — the whole school, and then, underneath that, an individual teacher.
Practically, this is the small piece of infrastructure that both messaging features are built on top of,
and it should land first, before either one, so neither ships without an off switch.
How it will work
School-level switch. An admin setting, off by default on a fresh install, that enables guardian ↔ teacher and class group messaging for the whole school.
Teacher-level override. Even with messaging enabled school-wide, an individual teacher can opt their own class out — some teachers will want it, some won't, and that's a legitimate choice at the classroom level too.
Clean disable, not just hidden. Turning messaging off hides the entry points in the UI and blocks new-thread creation at the permission layer — existing threads are preserved (not deleted) but become read-only, so no message history is lost if a school re-enables it later.
No partial state. If the school switch is off, the teacher-level override is irrelevant and hidden — one clear hierarchy, no confusing combination of settings.
Development plan
1Settings model
New messaging_enabled boolean on the School model, default False.
New messaging_enabled boolean on the class/section model, default True — inherits from the school switch, opt-out at the class level rather than opt-in.
2Enforcement at the permission layer
Thread-creation and message-send endpoints check both flags before allowing the action — enforced in the data/permission layer, not just by hiding a button in the UI.
Existing threads become read-only (viewable, not postable) if either flag flips to off after messages already exist.
3Admin & teacher UI
School settings page gets a clearly labeled messaging toggle with a short explanation of what turning it on commits the school to.
Per-class setting surfaced on the class settings page for teachers, only visible when the school switch is on.
4Testing & sequencing
Ship this before either messaging feature goes live, with automated tests confirming both messaging features respect the flags at the API level, not just in the UI.
Regression test: toggling off with active threads doesn't delete data, and toggling back on restores full functionality without re-creating threads.
Technical considerations
Defaulting to off school-wide keeps existing self-hosted installs unaffected until an admin makes a deliberate choice to enable it.
Enforcement has to live in the same permission layer as the rest of Notipa's role checks — a UI-only toggle would be trivially bypassable via direct API calls.
This is small in scope by design, so it can ship ahead of both messaging features without blocking on their full build-out.