Skip to main content

Parent-Teacher Meeting (PTM)

A teacher creates a PTM as a typed alert. It fans out as a MEETING announcement to the targeted sections. Parents see it on their PTM page (with the join link if it's online). Students see it under their school services. There's no booking yet — slot booking is exposed in the form as "Individual Meetings" but the parent-side surface today is a unified list with upcoming and past meetings.

At a glance​

Who can do thisTeachers schedule · Parents view & join · Students view (read-only)
Where it livesTeacher app /dashboard/alerts/ptm (and /dashboard/alerts/ptm/:id/edit) · Parent app /ptm · Student app /dashboard/school/ptm
Alert typeMEETING (priority MEDIUM by default)
Triggers notifications?Yes — push + in-app on publish, scheduled to send at scheduledAt
Related featuresNotice Board & Alerts · Notifications

How it flows​

Status lifecycle​

The parent app derives Upcoming vs Past purely from eventAt (or scheduledAt as fallback) compared to Date.now() — there's no explicit "Cancelled" or "Completed" status surfaced.

Step-by-step​

1. Teacher schedules the PTM​

  • App / route: Teacher app → /dashboard/alerts/ptm (create) or /dashboard/alerts/ptm/:id/edit (revise an existing one).
  • Form fields:
    • Meeting title (required).
    • Meeting type (radio):
      • Regular PTM — open meeting for all parents at scheduled time.
      • Individual Meetings — appointment-based, parents could book one-on-one slots.
      • Urgent Meeting — private meeting for selected students' parents only.
    • Purpose / Agenda (required, free text — "helps parents prepare").
    • Meeting Mode: Offline / Online.
    • Location (offline) or Meeting Link (online — accepts Google Meet, Zoom, any URL; parents can tap to join).
    • Meeting date & time (eventAt) — when the meeting happens. Past times allowed only when editing a meeting whose eventAt is already past (so a teacher can patch up history without breaking validation).
    • Attachments — S3-uploaded files.
  • Save vs Publish:
    • Save Draft persists with status = DRAFT and does not notify anyone.
    • Publish opens the AlertTargetScheduleSheet, where the teacher picks target classes / sections and the sendAt (when the alert notification fires). On confirm, status flips to PUBLISHED.
  • Publish is disabled until both meetingTitle and meetingAt are filled.

2. Notification fan-out​

  • At sendAt, all targeted students and their parents receive a push + in-app notification of type MEETING.
  • The notification deep-links into the parent's /ptm page (parent app) and the student's /dashboard/school/ptm?id=:id (student app, opening the detail drawer).

3. Parent views & joins​

  • App / route: Parent app → /ptm. If multiple children are linked, the page resolves a child via location.state.studentProfileId or falls back to the first linked student.
  • The page splits meetings into Upcoming (sorted ascending — soonest first) and Past (sorted descending — most recent first).
  • Each card shows: unread dot, title, description, meeting date/time, Mode badge (Online / Offline), Priority badge (HIGH / MEDIUM / LOW), and — if Online — a Join Meeting link that opens the meeting URL in a new tab.

4. Student views​

  • App / route: Student app → /dashboard/school/ptm.
  • Two sections: CurrentPTM (upcoming) and PastPTMList, both pulling MEETING-type student announcements.
  • Tapping a card opens PTMDetailDrawer with the agenda, location/link, mode, and attachments. The URL gains ?id=:id so the drawer is deep-linkable; closing it strips the param.
  • Read-only: students cannot book, RSVP, or chat from this surface.

5. Editing or rescheduling​

  • Teacher returns to the alerts list, taps the PTM, gets routed to /dashboard/alerts/ptm/:id/edit.
  • All fields are editable, including eventAt (past dates allowed for retroactive fixes) and meetingMode.
  • Re-publishing updates the existing alert; recipients see the updated card on next load.

Edge cases & things to test​

  • Online with no link: teacher publishes Online mode but leaves the link blank — parent card should not show a broken Join button.
  • Offline with empty location: same — should not crash; "Location" should just be empty.
  • Past eventAt at publish time: should be allowed only on edit (where the meeting is already past); on create, the date picker disables past dates.
  • Different eventAt vs scheduledAt: meeting at noon Friday but alert sends Wednesday morning — parent should see the Wednesday push but the card date should read Friday noon.
  • Multi-section publish: target Sections A + B — both parent groups get one alert each, no duplicates.
  • Multi-child parent: parent with kids in two sections, both having PTMs — switching the active student should swap the PTM list.
  • Notification deep-link: tap a MEETING push on parent app → lands on /ptm with the right card visible. On student app → opens /dashboard/school/ptm?id=:id and pre-opens the drawer.
  • Edit after parents have joined / read: read state and unread dot should persist; the edited card should not re-mark itself unread for everyone (or, conversely, should re-mark unread if the time changes — confirm intended behaviour).
  • Long meeting title / agenda: 500-char title — should clip in the card with line-clamp without breaking the layout.
  • Attachments: 0 attachments vs 5 attachments — parent and student detail surfaces should handle both gracefully.
  • Time zone: meeting date is stored UTC; verify both apps render in the device's local time, especially around midnight crossovers.
  • "Individual Meetings" type: today the form captures the type, but there's no parent-side slot-booking UI — verify the type round-trips through edit and that no UI advertises booking that doesn't exist.