Event¶
The event app models the event itself and its configuration. It is a
tenant app — every tenant’s schema has its own set of events (in practice one
event per tenant today; concurrent multi-event access is a future goal).
What it does¶
Event— the core record for a convention (name, slug, dates, timezone, logo, tenant). Itsslugis the primary key and is used to scope per-event data throughout the codebase.EventProperty— a flexible key/value configuration store. Each property has a stringid(e.g.register.checkin_procedure,vendors.separate_table_payment) and a JSONvalue. This is how modules get per-event settings without schema changes — see Event properties (concept) for the pattern.Domain resolution — an
Eventis reached via a subdomain or aCustomDomain(handled in the tenant app and resolved byEventSetupMiddleware).
Event properties you’ll see¶
The event__generate_properties management command seeds a comprehensive set of
default EventProperty rows per event. A few examples:
Property id |
Controls |
|---|---|
|
Reply-to/subject templating for registration emails |
|
The configurable check-in procedure steps |
|
Badge/label print template |
|
Whether attendee reg + table payment are split |
|
Vendor hotel booking integration |
|
Whether staff register through the staff portal |
|
Timeslot/email defaults for the schedule app |
Tip
When you add a new tunable behavior, prefer an EventProperty over a new model
field unless the value is structural. Read existing property keys before
inventing new ones — they are the most stable per-event extension point.
Key models¶
Event (pk = slug)
└─ EventProperty (name, value: JSONField)
Where to look¶
Models:
event/models.pyProperty seeding:
event/management/commands/event__generate_properties.py(run withall_tenants_commandto provision every tenant).Per-event config consumed across:
register/,vendors/,staff/,schedule/views.