ced4568/rootnode-academy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(offering): launch readiness, agreement requirements, guardian communications, website registration API

Browse Source 
- Registration is now server-authoritative: draft/cancelled/completed/full/window-closed
  offerings reject registration attempts with distinct error codes (assertRegistrationOpen).
- offering_agreement_requirements + conversion-time blocking on missing required
  agreements; accepted_by_type gained 'registrant' for an adult self-accepting before
  their student_id exists.
- computeOfferingReadiness() — a server-derived launch checklist (curriculum, instructor,
  schedule, location, capacity, registration window, agreements, curriculum package).
- Guardian communications wired into the existing Phase 5C notification system: a guardian
  email fallback in resolveRecipient(), a parallel enqueueForRegistration()/
  resolveRegistrationRecipient() pair for pre-account registration-stage notifications
  (registration_received/confirmed/needs_action, agreement_required, camp_operational_update),
  five new RootNode-branded templates. Same table, same worker, same masked admin view —
  no second notification system.
- public-offerings-routes.js: the unauthenticated, explicitly-allowlisted offering read API.
- POST /api/integrations/registrations: the website's idempotent registration submission
  contract, same shared-secret boundary as the existing enrollment integration endpoint.

Two real bugs found and fixed during this phase's own testing before any commit:
(1) the five new notification_type values were wired into the worker before the DB's own
CHECK constraint was widened to accept them — every registration-stage notification was
silently failing until a comprehensive smoke test caught it (036 fixes the constraint;
every previously-silent notification catch now at least logs).
(2) firing a notification right after a registration's insert, before its seat reservation
could still fail and roll the row back, created a real foreign-key violation on rollback —
fixed by reordering createRegistration() to validate -> reserve -> insert -> notify.

See docs/OFFERING_AND_REGISTRATION_MODEL.md and docs/PHASE8_ENROLLMENT_OPERATIONS.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
This commit is contained in:
ced4568
2026-08-26 23:59:11 -05:00
co-authored by Claude Sonnet 5
parent df5e39f767
commit 24eee80354
10 changed files with 585 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
platform/api/src/notification-worker.js
+17
View File
@@ -44,6 +44,23 @@ function renderFor(row) {
if (row.notification_type === 'password_changed') {
return templates.passwordChanged({ displayName });
}
// Phase 8 — registration-stage notifications. No token/public-origin dependency, so these
// never fail on missing PUBLIC_APP_ORIGIN config the way activation/reset do.
if (row.notification_type === 'registration_received') {
return templates.registrationReceived({ displayName, offeringName: row.metadata?.offering_name || 'your offering' });
}
if (row.notification_type === 'registration_confirmed') {
return templates.registrationConfirmed({ displayName, offeringName: row.metadata?.offering_name || 'your offering' });
}
if (row.notification_type === 'registration_needs_action') {
return templates.registrationNeedsAction({ displayName, offeringName: row.metadata?.offering_name || 'your offering', reason: row.metadata?.reason });
}
if (row.notification_type === 'agreement_required') {
return templates.agreementRequired({ displayName, offeringName: row.metadata?.offering_name || 'your offering', agreementTitle: row.metadata?.agreement_title || 'a required agreement' });
}
if (row.notification_type === 'camp_operational_update') {
return templates.campOperationalUpdate({ displayName, offeringName: row.metadata?.offering_name || 'your offering', message: row.metadata?.message || '' });
}
return null;
}