Event- und Festival-Datenmodell

Verwandte Doku: Events, Festivals, Festivaltage, Gebäude, Kontakte

Kern-Hierarchie

1. Festival
2. Festivaltag
3. Event
4. Event-Slot
5. Reservierung

Das ist die wichtigste operative Kette. Nicht jede Ebene ist auf jedem Datensatz zwingend.

Festival

• Gruppiert ein Programm über mehrere Tage.
• Kann direkt verknüpfte Events haben.
• Kann außerdem Festivaltage enthalten.

Festivaltag

• Repräsentiert ein Kalenderdatum innerhalb eines Festivals.
• Speichert Datum, Status und optional eine Beschreibung.
• Kann viele Events enthalten.

Im Event-Formular setzt die Auswahl eines Festivaltags automatisch das zugehörige Festival.

Event

Ein Event ist der Parent-Datensatz für Zeitplanung und Reservierungen.

Wichtige Felder:

• Titel
• Slug
• Kategorie
• Status
• Sichtbarkeit
• Beschreibung
• Titelbild
• Festival
• Festivaltag
• Gebäude
• Adresse
• Künstler

Buchungsrelevante Felder:

• Verkaufsstart / Verkaufsende
• Max. Tickets pro Anmeldung
• Kapazität Tickets
• Kapazität Reservierungen
• Slot-Auswahl erforderlich
• Warteliste erlauben
• manche Kategorien zeigen zusätzlich benötigte Volunteers und das Flag für Pflichtschulung

Hinweise:

• Das aktuelle Formular verlangt mindestens einen Slot.
• Die aktuelle öffentliche Seite nutzt die Event-ID in der URL, nicht den Slug.
• Bei veröffentlichten unlisted-Events funktioniert dieser öffentliche Link ebenfalls; sie sind nur für Link-Freigabe gedacht.
• allowReservations existiert im Schema, wird im Event-Formular aber derzeit nicht angezeigt.
• Events können außerdem eigene Felder für das öffentliche Anmeldeformular definieren.

Event-Slot

Slots sind Child-Datensätze unter genau einem Event.

Wichtige Felder:

• Titel
• Start
• Ende
• Ganztägig
• Gebäude
• Kapazität
• Vortragende Person
• Interne Notizen
• Verkaufsstart / Verkaufsende

Verhalten:

• Das Slot-Gebäude kann das Event-Gebäude überschreiben.
• Slot-Verkaufsfenster können feiner sein als Verkaufsfenster auf Event-Ebene.
• Beim Löschen eines Slots werden Reminder- und Kalender-Sync-Daten bereinigt.

Reservierung

Reservierungen gehören zu genau einem Event und können optional auf einen Slot zeigen.

Wichtige Felder:

• Benutzer
• Vollständiger Name
• E-Mail
• Telefon
• Notizen
• Datensatz-Status
• Antwortstatus
• Teilgenommen
• Favorit
• Slot
• Bestellung
• Läuft ab am
• Check-in am

Die aktuelle Event-UI nutzt Reservierungen inzwischen in einem Admin-Workflow und nicht nur als passive Liste. Mitarbeitende können vorhandene aktive Workspace-Mitglieder zu einem Event hinzufügen, optional einem Slot zuordnen, zwischen eingeladen, angenommen, Warteliste und abgesagt / storniert verschieben und Reservierungen entfernen.

Wenn ein angenommener Platz frei wird, zieht das Backend automatisch den nächsten Wartelisten-Eintrag nach, falls nötig innerhalb desselben Slots. Bei Sneak-Preview-Abläufen werden Favoriten zuerst bevorzugt, sonst rückt der älteste Wartelisten-Eintrag nach.

Diese Admin-Aktionen aktualisieren nur Reservierungsdaten. Sie verschicken selbst keine Reservierungs-E-Mails.

Reservierungen können außerdem von nicht angemeldeten Besucher*innen auf einer veröffentlichten öffentlichen oder unlisted-Event-Seite angelegt werden. Dieser Ablauf kann E-Mail-Bestätigung verlangen, bei voller Kapazität auf die Warteliste setzen, eigene Formularantworten getrennt vom Reservierungs-Basissatz speichern und workspace-konfigurierbare Verifizierungs-, Bestätigungs- und Wartelisten-E-Mails verwenden.

Weitere verknüpfte Datensätze

Künstler

• Wird als Kontakt gespeichert.
• Über das Feld artist mit dem Event verknüpft.

Gebäude

• Auf Event-Ebene und optional zusätzlich auf Slot-Ebene verknüpft.
• Dient für Venue-Kontext und Slot-spezifische Überschreibungen.

Adresse

• Wird getrennt vom Event gespeichert.
• Wird genutzt, wenn das Event eine manuelle Adresse statt oder zusätzlich zum Gebäude braucht.

Titelbild

• Wird als Datei gespeichert.
• Wird auf der Event-Detailseite und der öffentlichen Event-Seite verwendet.

Regel für öffentliche Sichtbarkeit

Die öffentliche Event-Seite liefert nur Events zurück, die gleichzeitig:

• published
• public oder unlisted

sind.

unlisted bedeutet, dass die Seite per direktem Link erreichbar bleibt, aber nicht breit auffindbar sein soll. Auf der öffentlichen Seite werden nur veröffentlichte Slots gezeigt.

Backend-Datensätze, die die Event-UI noch nicht abdeckt

Das Schema definiert außerdem:

• Tickettypen
• Reservierungspositionen
• Bestellungen
• Bestellpositionen

Diese Datensätze gehören zum größeren Commerce-Modell rund um Events, werden aber nicht über die aktuellen Event-Admin-Screens aus Events verwaltet.