System Architecture & Data Model

Key Files

• concert.html — Past-event recap page with a donate CTA (no longer a registration form as of July 2026 — the June 6 concert has passed)
• admin.html — Admin panel with 6 tabs
• src/concert-init.js — Registration/payment logic (Supabase, EmailJS, SMS, Mailchimp). No longer loaded by any page since concert.html's registration form was retired — kept in the repo, unused, in case registration is ever reintroduced for a future event
• src/db.js — All concert Supabase queries
• src/admin.js — Admin panel logic
• src/config.js — Concert API credentials

External Services

Concert Database Tables

EmailJS Templates

• template_ir6wkd9 — Performer confirmation (includes performers list, time slot, amount paid)
• template_goj792l — Donor & Volunteer confirmation (registration_type, donation_amount, volunteer_interest)

Two Schools

All school tables have a school_id foreign key. The active school is stored in localStorage as rwm_school_id and persists across pages.

School Modules & Pages

Note: school/students.html, staff.html, enrollments.html, etc. above are legacy standalone pages — most were converted to tiny redirect stubs (location.replace('admin.html#<section>')) after their original login forms were found to be non-functional. The actual UI lives in the school/admin.html single-page app.

Cross-System Data Flow

When a Donor or Volunteer registers on the concert page and completes their submission, their data is automatically saved to the school Supabase (RWM-PE non-profit):

• Donor → saved to donors table in school DB
• Volunteer → saved to volunteers table in school DB

This uses a secondary Supabase client in concert-init.js with persistSession: false (no auth required — public INSERT policies on both tables).

localStorage Keys

Overview

The ESL platform lives inside the school Supabase project and adds three layers on top of the existing admin system: a teacher-facing admin section, a student-facing PIN portal, and a shared messaging thread between them. Full history is in docs/esl-platform-plan.html (status banner at the top explains the actual build order vs. the original speculative plan). User-facing guides: docs/esl-teacher-guide.html and docs/esl-student-guide.html.

Tables (school Supabase project)

All four tables use the same blanket RLS policy as the rest of the school system: FOR ALL USING (auth.uid() IS NOT NULL) — no per-user scoping, consistent with every other table in this project. This means the anon key has zero direct access; the student portal never queries these tables directly (see RPCs below).

Teacher role scoping

The previously-unused users.role column (supabase-school-schema.sql) is read on login in school-admin.js. When role = 'teacher', the sidebar is filtered down to just ESL Classes and Security, and the default landing section becomes ESL Classes instead of the dashboard. Accounts with no matching users row (e.g. pre-existing admins) default to full access — purely additive, nothing broke for existing users when this was added.

Student portal — RPCs (SECURITY DEFINER)

The student portal (school/esl-portal.html / src/school-esl-portal.js) never authenticates with Supabase Auth — there's no student login session. Instead, every action re-verifies login_code + SHA-256 pin_hash against the table directly inside a SECURITY DEFINER Postgres function, the same pattern the concert project already used for get_slot_capacity/check_duplicate_registration.

Session persistence is just {login_code, pin_hash, expiry} in localStorage (7 days), silently re-calling esl_portal_login on page load — no server-side session table. Brute-force lockout (5 attempts → 10 min) is also tracked client-side in localStorage; a soft deterrent given static hosting has no server-side rate limiting.

Overview

A generic, reusable email notification system built 2026-07-25 after a volunteer application was silently lost to a broken form (stale JS reference on the public volunteer page — see the "Broken pages" incident notes). Any table/event in the school project can be wired up to send an email without new code — just a database row and a small trigger.

Components

Deploying/updating the notify function

The Supabase Dashboard's paste-based Edge Function editor proved unreliable for this file (repeated silent truncation/corruption on an ~80-line paste). The Supabase CLI is installed locally (brew install supabase/tap/supabase) and authenticated — prefer it for any future changes:

supabase functions deploy notify --project-ref cxsmoquefrxswkyjzzni --no-verify-jwt

The --no-verify-jwt flag is required: Database triggers send our own custom secret, not a Supabase JWT, so the platform's default JWT gate would otherwise reject every call before the function's own code (which does its own auth check) ever runs.

Adding a notification for a new table/event

1. Insert a row into notification_rules (table_name, event, recipient_email, subject/body templates using {{field}} placeholders matching that table's columns — recipient_email also supports templating, e.g. {{email}} to notify the record's own address).
2. Add a Postgres trigger following the pattern in supabase-notify-webhook-trigger.sql or supabase-notify-volunteer-approved.sql — a small plpgsql function calling net.http_post(...) with the same URL/secret header, then CREATE TRIGGER ... AFTER <EVENT> ON public.<table> ... EXECUTE FUNCTION ....

No code changes or redeploys needed for a new table — the notify function itself is fully generic.

• Both Supabase projects use Row Level Security (RLS) on all tables
• School admin tables require auth.uid() IS NOT NULL — admin login required
• Public INSERT policies exist only on donors and volunteers (for concert cross-save) and registrations (concert)
• Public SELECT policy exists on schools (for the concert page to find the non-profit school ID)
• Anon keys are safe to expose client-side — they are scoped by RLS policies
• Service role keys are never used client-side