Exactly what fires a push, who receives each target, and the guarantees that keep it from reaching the wrong person. Every rule below is read straight from the production code.
Push is sent only when content is published — never on reads, logins or background activity. Only an Admin or a Residential Director / Assistant RD can publish, and they choose the audience at that moment.
Published in News. Push title: "New announcement"; body is the announcement title.
opens /announcementsSame event with priority = urgent. Push title becomes "⚠ Urgent announcement" so it stands out on the lock screen.
opens /announcementsPublished in Polls. Push title: "New poll"; body is the question.
opens /pollsWhen the publisher selects a target, the server resolves the recipients from the database. Tap a target to light up the roles that receive it.
Not by configuration — by construction. They are excluded in the recipient query, and again by two independent server guards below.
No subscription is ever stored for these roles, and the server refuses to send to them even if a stale subscription exists.
Shared devices were the original risk — the same phone used by several roles across a summer. These close it at the source.
A push subscription belongs to the device, not the login. On each sign-in the device is re-claimed for the current user, so a phone that was an admin stops receiving the moment it becomes a parent.
Subscriptions are created only through a server function that validates the role first. A parent / school / instructor is rejected and any subscription on that device is purged. secure-push
Before delivering, the sender sweeps out any subscription owned by a no-push role, then re-verifies the owner of each remaining subscription one by one. Forbidden rows are deleted, never sent. send-push
✓ Verified in production code — VAPID Web Push, no third-party broker