Systems¶
Midsummer is organized as a set of Django apps. Each app owns a slice of convention operations. This section explains what each app does at a level useful to a developer touching it for the first time.
For the cross-cutting theory (multi-tenancy, the form system, permissions, payments), see Concepts & Theory. For the exhaustive data model and API surface, see Reference.
How the apps fit together¶
Tenant (public schema) ← owns everything below
└─ Event ─┬─ RegistrationForm → Registration → RegistrationLevel / RegistrationItem
├─ VendorType → Vendor → Jury / Juror / VendorDisplay
├─ Category / Track / Room → Panel → Slot / Interest / Comment
├─ Department → ModuleOwnership / Shift / HR
├─ ShopItem → ShopCart → ShopOrder → ShopFulfillment
└─ RapidCheckinTerminal / EventBadgeSettings / DigitalSignageDisplay
User (public schema, shared) ← one identity across all tenants
└─ Membership (per-tenant role) + PersonnelFile + auth (MagicLink/MFA)
The “app” naming note¶
The frontend folders ui/ and tenantui/ are Angular apps, but in this
section “app” means a Django application. The Angular SPAs consume the REST +
WebSocket APIs that these Django apps expose.
App quick-reference¶
App |
What it’s for |
Key models |
|---|---|---|
Identity, auth, personnel files |
|
|
The event itself + per-event config |
|
|
Registration forms, levels, check-in, badges |
|
|
Dealer applications, jury voting, task flow |
|
|
Departments, roles, HR, shifts |
|
|
Panels, rooms, tracks, signage, static pages |
|
|
E-commerce with Stripe + QR fulfillment |
|
|
Tenant org, domains, memberships |
|
|
Self-service terminal endpoints |
kiosk views under |