Event- und Festival-Datenmodell

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

Kern-Hierarchie

1. Festival
2. Festivaltag
3. Event
4. Event-Slot
5. Zulassung einer teilnehmenden Person

Das ist die wichtigste operative Kette. Festival und Festivaltag sind optional; jedes nicht archivierte Event hat aber mindestens einen aktiven Slot, weil Event-Termine auf Slots gespeichert werden. Zulassungen bleiben optional.

Festival

• Gruppiert ein Programm über mehrere Tage.
• Kann direkt verknüpfte Events haben.
• Kann außerdem Festivaltage enthalten.
• Kann die lokale Uhrzeit festlegen, zu der ein Programmtag in den nächsten wechselt. Ohne Grenze folgen Programmtage den Kalenderdaten.

Festivaltag

• Repräsentiert ein Programmdatum innerhalb eines Festivals. Bei einer Grenze von 06:00 gehört beispielsweise ein Slot um 01:00 zum vorherigen Datum.
• Speichert Datum, Status und optional eine Beschreibung.
• Kann viele Events enthalten.

Im Event-Formular setzt die Auswahl eines Festivaltags automatisch das zugehörige Festival und verschiebt anders datierte Slots auf diesen Programmtag; Uhrzeit und Dauer bleiben erhalten. Danach haben Slot-Änderungen Vorrang: Ein einzelner Programmtag setzt den passenden Festivaltag, Slots über mehrere Programmtage entfernen die einzelne Tageszuordnung.

Event-Typ

Ein Event-Typ ist eine eigenständige Workspace-Konfiguration, die vor dem Anlegen eines Events gewählt wird. Er hat einen stabilen Key, eine Bezeichnung, Beschreibung und ein Icon und speichert direkt die Event- und Slot-Formularlayouts, Beziehungsanforderungen, Titel-, Bild- und Adressquellen, Volunteer-Funktion, benannte Slot-Regeln, Admission für das ganze Event und seine Slots sowie die Richtlinie für zusätzliche Slots. Beim Anlegen wird eine Startvorlage oder ein leeres Layout in den Typ kopiert; danach stammt das Verhalten aus dem gespeicherten Typ selbst.

Typen können einen Slot, eine feste Gruppe benannter Slots oder freie Slots verwenden. Wird ein Typ stillgelegt, verschwindet er aus der Auswahl für neue Events, ohne bestehende Events zu trennen. Ein unbenutzter Typ kann gelöscht werden.

Event

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

Wichtige Felder:

• Titel
• Slug
• Event-Typ
• 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
• Event-Typen mit Volunteers können zusätzlich eine benötigte Anzahl und das Flag für Pflichtschulung anzeigen

Hinweise:

• Die effektiven Darstellungsregeln beziehen angezeigten Titel und Titelbild unabhängig voneinander vom Event, Gebäude oder von der Künstler*in. Event-spezifische Abweichungen gelten nur, wenn sie erlaubt sind; andernfalls werden spätere Änderungen am Quelldatensatz sichtbar, ohne einen kopierten Wert am Event zu speichern.
• Der Typ legt außerdem fest, ob die Adresse zum Event gehört oder strikt vom Gebäude kommt. Für eine Gebäudeadresse gibt es keine Event-spezifische Abweichung.
• Slot-Anforderungen kommen direkt aus dem Event-Typ. Er kann benannte Rollen-Slots verlangen, ihre Anzahl begrenzen und zusätzliche unbenannte Slots erlauben oder verbieten. Ein Typ ohne benannte Rollen erzeugt trotzdem einen unbenannten 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.
• Anmeldung und Ticketing können für das ganze Event unabhängig von seinen Slot-Rollen aktiviert werden. Eine Anmeldung für das ganze Event braucht keinen Slot; bei slotbezogener Anmeldung ist er erforderlich.
• Jedes Event kann ein veröffentlichtes, nicht gelistetes Anmeldeformular besitzen. Es verwendet die Fragen und Einsendungen des Forms-Modells, wird aber vom Event aus bearbeitet und erscheint nicht in der normalen Formularliste.
• Events mit aktivierten Volunteers können nicht archivierte Workspace-Mitglieder unabhängig von Reservierungen zuteilen. Benötigte und zugeteilte Personen fließen in die Volunteer-Abdeckung des Festivals ein.
• Ein veröffentlichtes Event in einem Festival mit angelegten Tagen darf keine datierten Slots außerhalb dieser Programmtage haben. Entwürfe können während der Bearbeitung vorübergehend unvollständig bleiben.

Event-Slot

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

Wichtige Felder:

• Titel
• Rolle
• Zeitform
• 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.
• Eine Rolle kann eine range mit Start und Ende oder einen instant mit einer Uhrzeit ohne Ende definieren. Alte und freie Slots verwenden standardmäßig range; ein Zeitpunkt ignoriert und entfernt ein altes Ende.
• Der Event-Typ kann Mindest- und Höchstmengen pro Rolle festlegen und die jeweils passenden Zeitfelder 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.
• Der Festivaltag eines datierten Slots wird in der Festival-Zeitzone und anhand der Programmtag-Grenze ermittelt. Anlegen, Bearbeiten, Löschen und Kalender-Verschiebungen von Slots berechnen die Festivaltag-Zuordnung des Events neu.
• Beim Löschen eines Slots werden Reminder- und Kalender-Sync-Daten bereinigt.

Zulassung und Reservierung

Die Teilnehmendenliste basiert auf Zulassungen. Eine Zulassung identifiziert eine Person an einem Event und kann mit Slot, Benutzer*in, Kontakt, Reservierung, Bestellung und scannbarem Nachweis verknüpft sein. Die Herkunft unterscheidet Einladung, öffentliche Anmeldung, Team-Aktion und Ticket-Ablauf; der Status umfasst eingeladen, Bestätigung ausstehend, angenommen, Warteliste, abgelehnt, abgelaufen und storniert.

Reservierungen speichern weiterhin anmeldespezifische Angaben wie Telefon, Notizen, Teilgenommen- und Favorit-Flag sowie die E-Mail-Bestätigung. Öffentliche Anmeldungen und direkte Ergänzungen von Workspace-Mitgliedern erzeugen oder aktualisieren eine Reservierung und spiegeln sie in eine Zulassung. Ein direkt ergänzter Kontakt erhält eine Zulassung ohne Reservierung. Der Tab Teilnehmende führt beide Wege mit reinen Einladungs- und Ticket-Zulassungen zusammen.

Mitarbeitende können Kontakte, Kontaktgruppen, Benutzer*innen und Benutzergruppen auflösen und danach entweder persönliche Einladungen senden oder die Personen direkt mit einem gewählten Status ergänzen. Einträge ohne E-Mail und doppelte Ziele werden übersprungen; Einladungen und direkte Kontakt-Ergänzungen überspringen außerdem bereits aktive Zulassungen, während eine bestehende Mitgliederreservierung aktualisiert werden kann. Beim Entfernen einer angenommenen Reservierung rückt gegebenenfalls der nächste geeignete Wartelisten-Eintrag desselben Slots nach.

Einladungs-Claims werden nur als Hash gespeichert. Solange der persönliche Bearer-RSVP-Link gültig ist, kann die Person annehmen, ablehnen oder eine frühere Antwort ändern. Eine erfolgreiche Zusage stellt bei freier Kapazität einen QR-Nachweis aus und erzeugt eine abgeschlossene, kostenlose Anmelde-Bestellposition mit dem Zahlungsstatus „nicht erforderlich“; eine spätere erneute Zusage derselben Zulassung verwendet sie wieder. Ohne Kapazität folgt stattdessen die Warteliste, eine Ablehnung widerruft einen aktiven Nachweis. Die Workspace-Einstellungen können zusätzlich eine eigene Zusage-E-Mail mit QR-Code und optionalem PDF-Ticket aktivieren.

Nicht angemeldete Besucher*innen können auf einer veröffentlichten öffentlichen oder unlisted-Event-Seite eine Reservierung anlegen. Dieser Ablauf kann eine E-Mail-Bestätigung verlangen und bei voller Kapazität auf die Warteliste setzen. Das Event-eigene Formular erzeugt eine normale Einsendung mit Quelle event, die mit der Reservierung verknüpft ist; angenommene Antworten eingeladener Personen sind stattdessen mit ihrer Zulassung verknüpft.

Weitere verknüpfte Datensätze

Event-Zuteilung

• Verknüpft ein nicht archiviertes Workspace-Mitglied mit einem Event, optional mit einem Event-Slot und dem zugehörigen Festival. Verwaltete Mitglieder ohne Anmeldekonto werden unterstützt.
• Beim Staffing für das ganze Event gibt es eine Zuteilung pro Event und Mitglied. Beim Slot-Staffing gibt es eine Zuteilung pro Event, Mitglied und Slot; dieselbe Person kann daher mehrere Aufgaben an einem Event übernehmen, wenn die Slots verschieden sind.
• Der Lebenszyklus ist requested, confirmed, declined oder withdrawn. Nur bestätigte Zuteilungen füllen die Volunteer-Zahl eines Slots und die Festival-Abdeckung; die anderen Status bleiben als Historie erhalten.
• Neue Zuteilungen sind nur für Event-Typen mit aktivierten Volunteers erlaubt. Manuelle Änderungen durch Organisator*innen werden sofort gespeichert und benötigen Aktualisierungszugriff auf Events; Self-Signup folgt zusätzlich den Typ-, Slot- und Festivalregeln.
• Festival-Limits pro Person und Tag verwenden Programmtage statt Kalender-Mitternacht.
• 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.
• Eine Event-eigene Adresse kann als freie Textzeile oder in strukturierten Adressfeldern gespeichert werden. Beim Aufteilen oder Zusammenfassen wechselt das Event-Formular zwischen diesen Formen, damit Anzeige, Export und Geocoding dieselbe Quelle verwenden.
• Bei einer Gebäudeadresse ist die Adresse des verknüpften Gebäudes maßgeblich und das Formular bietet keine Abweichung an. Eine frühere Event-Adresse wird ignoriert und beim nächsten Speichern des Event-Formulars entfernt; Event-Reads und Public-API-Projektionen liefern die Gebäudeadresse.

Titelbild

• Wird als Datei gespeichert.
• Wird auf der Event-Detailseite und der öffentlichen Event-Seite verwendet.
• Wenn es in den Workspace-Einstellungen aktiviert ist, steht das effektive Event-Titelbild auch über Einladungs-E-Mail, Zusage-E-Mail mit Ticket und RSVP-Seite. Events ohne Bild behalten das reine Textlayout.

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.

Ticketing-Datensätze

Ticketprodukte, Bestandspools, Bestellungen, Zahlungen, Nachweise, Gutscheine, Aktionen, Rückerstattungen und Scans bilden ein getrenntes Commerce-Modell. Ticketprodukte verwenden nicht den gewöhnlichen Produkte-Katalog.

Eintrittsprodukte können zu Festival, Event-Typ, Slot-Rolle, Event oder Slot gehören. Event-Bearbeiter*innen legen Tickets für das ganze Event, Slots und Slot-Rollen im Tickets-Tab des Events an; geerbte Produkte bleiben Eigentum ihrer Quelle. Produkte werden von beiden Modi gemeinsam verwendet, ihre Bestandspools und Verkäufe gehören dagegen zum Test- oder Livemodus.

Die Event-Detailseite verwaltet Ticketprodukte, Eintritts-Gates und Scanner-Geräte, nicht aber Checkout oder Bestellungen von Käufer*innen. Der gehostete Shop und die privaten Bestellseiten sind unter Ticketing beschrieben.