ced4568andClaude Sonnet 5
788fb197e0
New: PHASE8_ENROLLMENT_OPERATIONS.md (phase summary), WINTER_BREAK_CAMP_OPERATIONS.md (the real operational walkthrough), REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md, OFFERING_ADMIN_GUIDE.md. Updated: ROOTNODE_ACADEMY_BUSINESS_AND_PRODUCT_ARCHITECTURE.md (BUILT NOW/PHASE 8 BUILT table), OFFERING_AND_REGISTRATION_MODEL.md (both ordering bugs, launch readiness, registration enforcement), STUDENT_GUARDIAN_DATA_MODEL.md (guardian communications now wired), WEBSITE_ENROLLMENT_INTEGRATION.md (the real, live registration contract with worked examples, replacing the old speculative future-flow section), platform/README.md (test list). Co-Authored-By: Claude Sonnet 5 <[email protected]>
70 lines
4.0 KiB
Markdown
70 lines
4.0 KiB
Markdown
# Offering Admin Guide
|
|
|
|
Phase 8 — how to actually run an offering from `/admin` → Offerings, end to end. Pairs with
|
|
`docs/OFFERING_AND_REGISTRATION_MODEL.md` (the underlying data model) and `docs/
|
|
WINTER_BREAK_CAMP_OPERATIONS.md` (the specific Winter Break Camp walkthrough).
|
|
|
|
## Creating an offering
|
|
|
|
**Offerings → Create offering.** Required: offering ID, URL slug, name, program, delivery mode.
|
|
Optional at creation: capacity (blank = unlimited), a location. Dates, the registration window,
|
|
organization, cohort, curriculum package, and agreement requirements are all set from the
|
|
offering's own detail page after creation — a new offering always starts `draft`, invisible to
|
|
the public offerings API and closed to registration, so there's no rush to fill in everything
|
|
before saving.
|
|
|
|
## The detail page
|
|
|
|
Opening an offering shows:
|
|
|
|
- **Overview** — status, seats, and the only status-transition buttons the offering can
|
|
actually take next (the ones the UI doesn't show are ones the server would reject anyway —
|
|
see `docs/OFFERING_AND_REGISTRATION_MODEL.md`'s transition diagram).
|
|
- **Launch readiness** — a live, server-computed checklist (curriculum, instructor, dates,
|
|
location, capacity, registration window, agreements configured). This is the same check the
|
|
server itself could use to gate opening registration — it is never just a frontend hint.
|
|
- **Required agreements** — which agreement definitions this offering requires before a
|
|
registration can convert to enrollment, with a form to add another.
|
|
- **Registrations / roster** — every registration against this offering, with a form to add one
|
|
directly (useful for phone/in-person sign-ups an instructor is entering by hand).
|
|
|
|
## Moving an offering through its lifecycle
|
|
|
|
`draft → published → enrollment_open → full/in_progress → completed`, or `→ cancelled` from
|
|
anywhere non-terminal. Only real, server-allowed transitions ever appear as buttons. `full` is
|
|
not automatic — an offering set to `enrollment_open` that happens to be at capacity will reject
|
|
new registrations with a clear error, but only moves to the visible `full` status when someone
|
|
explicitly sets it (or the very next registration attempt trips it) — check the readiness
|
|
panel/registration list to know why registration is currently unavailable.
|
|
|
|
## Working a registration
|
|
|
|
Open a registration from the offering's roster to see its own detail: registrant/guardian info,
|
|
agreement status (required vs. accepted vs. missing), lifecycle transition buttons, and its
|
|
communication history (every notification queued for it, with recipient always masked). Once a
|
|
registration is `confirmed` and every required agreement is accepted, **Convert to enrollment**
|
|
appears — this is the one action that creates the real student account (or matches an existing
|
|
one), the real academic enrollment, and real cohort membership if the offering has a cohort.
|
|
|
|
## Agreements
|
|
|
|
**Agreements** (reachable from an offering's "Required agreements" section) lets you define a
|
|
new agreement (title + a plain-language summary — never legal text, see `docs/
|
|
STUDENT_GUARDIAN_DATA_MODEL.md`) and associate it with any offering that needs it. A registration
|
|
cannot convert to enrollment while any required agreement is unaccepted.
|
|
|
|
## Guardians
|
|
|
|
A minor's registration always carries a linked guardian — create one from the registration form
|
|
when registering a minor by hand, or let the website integration create/match one automatically
|
|
from a real submission (see `docs/WEBSITE_ENROLLMENT_INTEGRATION.md`). Guardian records are
|
|
admin/owner-only — a plain instructor's cohort access to a student's academic progress is
|
|
unchanged, but guardian contact detail is not part of that.
|
|
|
|
## What the admin UI deliberately does not do
|
|
|
|
No pricing/payment fields, no legal-document authoring, no bulk email composer — every
|
|
communication is a templated, transactional notification triggered by a real lifecycle event
|
|
(see `docs/REGISTRATION_AND_GUARDIAN_COMMUNICATIONS.md`), never a free-form message an admin
|
|
types and blasts out.
|