Data model reference¶

A map of the major models and their relationships. The complete field-level reference lives in documentation/data-models.md (maintained by the syncer workflow).

Schema split¶

public schema (shared): Tenant, Domain, CustomDomain, User, Membership, PersonnelFile, MagicLink, Multifactor, AuthenticationState, plus Django core apps and oauth2_provider.
Tenant schemas (per-org): Event, EventProperty, and all event data (register, vendors, staff, schedule, shop, etc.).

See Multi-tenancy.

High-level relationship map¶

Tenant (public schema)
  └── Domain / CustomDomain ── resolves ──> request.tenant + request.current_event
        └── Event ─┬─ RegistrationForm ─ Registration ─ RegistrationLevel / RegistrationItem
                   ├─ VendorType ─ Vendor ─ Jury ─ Juror ─ JuryRating / VendorDisplay
                   ├─ Category / Track / Room ─ Panel ─ Slot / Interest / Comment
                   ├─ Department ─ ModuleOwnership / JobApplication / Shift / ShiftSchedule
                   ├─ ShopItem ─ ShopCart ─ ShopOrder ─ ShopFulfillment
                   ├─ RapidCheckinTerminal / EventBadgeSettings / BadgeNumberSequence
                   └─ DigitalSignageDisplay / StaticPage
User (public schema, shared)
  └── Membership (per-tenant role) + PersonnelFile + auth (MagicLink/Multifactor)
Stripe ── products/prices/webhooks ──> Registration/Vendor/Shop payment models
Celery workers <── queues ── register/print/badge/receipt/backend-interface tasks
Channels WS ── jury voting + staff ping ──> ui SPA

Patterns across models¶

JSON field schemas — RegistrationForm.fields, VendorType.form/tasks, ShopItem.form, Category.form store the form definition; Registration.data/Vendor.data/Panel.data store the submission. See the custom form system.
EventProperty key/value — flexible per-event config as (name, value=JSON) rows. See Event.
Status workflow — vendor/panel/fulfillment apps carry status machines (submitted → approved/rejected/waitlisted → archived; pending → validated → fulfilled → cancelled).
Audit logging — append-only log models per mutation surface. See Audit logging.
Stripe linkage — stripe_checkout_id on registrations/orders; products/ prices auto-managed in save(). See Payments.

Notable model families¶

register¶

RegistrationForm, Registration (data JSON, is_paid, qr_code, checkin_time), RegistrationLevel (Stripe price, included_merch), RegistrationItem (merch, options), EventBadgeSettings, BadgeNumberSequence, BadgeNumberAuditLog, RegistrationMerchAdjustmentLog, RegistrationTierUpgradeAuditLog, RegistrationEditLog, StaffManagementMessage, RapidCheckinTerminal, CheckinKiosk, NameWatchListEntry, RegistrationAssociationRequest.

vendors¶

VendorType (form, tasks), Vendor (data, status, task_completions), VendorMessage, Jury, Juror, JuryRating, VendorDisplay.

staff¶

Department, ModuleOwnership, DepartmentTitle, DepartmentTitleAssignment, Shift, ShiftSlot, ShiftSlotBid, ShiftAssignment, OpenPosition, PositionApplication, OnboardingFlow, OnboardingRecord, TransferRequest, AuditLog.

schedule¶

Category, Track, Room, Panel (data), Slot, interest/comment models, DigitalSignageDisplay, StaticPage.

shop¶

ShopItem (form), ShopCart, ShopOrder (snapshot), ShopFulfillment.

tenant¶

Tenant (schema_name), Domain, CustomDomain (status lifecycle), Membership.

Deep dive¶

For every model and field, read documentation/data-models.md — it is the maintained source of truth.