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-Typ

Ein Event-Typ ist eine Workspace-eigene Konfiguration, die vor dem Anlegen eines Events gewählt wird. Er hat einen stabilen Key, eine Bezeichnung und ein Icon und speichert das Event- und Slot-Formularlayout aus seiner Startvorlage. Seine Basis-Kategorie verbindet ihn mit versionierten Slot- und Zulassungsregeln. Wird ein Typ stillgelegt, verschwindet er aus der Auswahl für neue Events, ohne bestehende Events zu trennen.

Kategorievertrag

Ein Kategorievertrag ist die versionierte Richtlinie für alle Event-Typen mit derselben Basis-Kategorie. Er weist stabile Slot-Rollen zu und steuert Mindest- und Höchstmengen, standardmäßige Erzeugung, Pflichtangaben vor der Veröffentlichung, Admission, Kapazitätsbereich, Buchungsregel und öffentliche Sichtbarkeit. Außerdem speichert er Regeln für eigene Slots, Beziehungen, Darstellung und den Standard für Admin-Reservierungen.

Pro Basis-Kategorie kann es einen Entwurf und einen aktiven Vertrag geben. Neue Events speichern die bei ihrer Erstellung aktive Vertragsversion; die Aktivierung einer späteren Version schreibt bestehende Events nicht um.

Event

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

Wichtige Felder:

• Titel
• Slug
• Event-Typ
• gespeicherter Kategorievertrag
• 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
• Warteliste erlauben
• manche Event-Typen zeigen zusätzlich benötigte Volunteers und das Flag für Pflichtschulung

Hinweise:

• Die effektiven Darstellungsregeln können angezeigten Titel und Titelbild vom Event, Gebäude oder Künstler beziehen. Event-spezifische Abweichungen gelten nur, wenn diese Regeln sie erlauben.
• Slot-Anforderungen kommen aus dem gespeicherten Kategorievertrag. Er kann benannte Rollen-Slots verlangen, ihre Anzahl begrenzen und zusätzliche eigene Slots erlauben oder verbieten.
• 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.
• Ob Reservierungen möglich sind und ein Slot gewählt werden muss, wird aus den effektiven Admission-Regeln der Slot-Rollen abgeleitet.
• Events können außerdem eigene Felder für das öffentliche Anmeldeformular definieren.
• Benötigte Volunteers auf Events fließen in die Volunteer-Abdeckung des Festivals ein.

Event-Slot

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

Wichtige Felder:

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

Verhalten:

• Ein Rollen-Slot zeigt die Rollenbezeichnung als Titel und kann keinen separaten Titel speichern. Eigene Slots verwenden ihren eigenen Titel.
• Der gespeicherte Kategorievertrag kann Mindest- und Höchstmengen pro Rolle festlegen und Start oder Ende vor der Veröffentlichung verlangen.
• Die Admission einer Slot-Rolle ist none, registration, tickets oder mixed; daraus wird die öffentliche Reservierbarkeit abgeleitet.
• Eine eigene Slot-Kapazität überschreibt die Event-Kapazität. Ohne Override werden Event-Kapazität sowie gebuchte und wartende Personen als gemeinsamer Pool für die betreffenden Geschwister-Slots gezählt.
• 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

Event-Zuteilung

• Verknüpft eine Workspace-Benutzerin oder einen Workspace-Benutzer mit einem Event und optional mit dem zugehörigen Festival.
• Steuert die Anzahl zugeteilter Volunteers in Festivalübersichten.
• Die Volunteer-Timeline des Festivals gruppiert Zuteilungen nach Erstellungsdatum in Einblick, nicht nach Eventdatum.

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.