Was wir an Zeitplanr ändern, wann — und warum. Eine offene Übersicht für Hosts und Gäste.
Neue Funktion
Taktung der Terminauswahl frei wählbar
•Neuer optionaler Schalter pro Termintyp unter „Erweiterte Einstellungen": die Taktung der angebotenen Startzeiten lässt sich jetzt von der Meeting-Dauer entkoppeln.
•Beispiel: Meeting-Dauer 60 Minuten, Taktung „Alle 30 Minuten" → Gäste sehen 10:00, 10:30, 11:00, 11:30 … Sobald jemand einen Slot bucht, blendet das System die überlappenden Slots automatisch aus.
•Funktioniert in beiden Modi: „Wochenplan" und „Bestimmte Tage".
•Standardwert: „Standard (= Meeting-Dauer)" — alle bestehenden Termintypen bleiben unverändert, kein Eingriff nötig.
Warum: Reaktion auf konkretes Nutzer-Feedback: ein Host wollte 60-Minuten-Termine im 30-Minuten-Takt anbieten und behalf sich bisher mit zwei überlappenden Wochen-Verfügbarkeitsfenstern (10:00–17:00 und 10:30–16:30) — clever, aber nicht in den „Bestimmten Tagen" portierbar. Die neue Einstellung macht den Trick überflüssig und funktioniert in beiden Terminmodi gleich.
Richtlinie
Buchungsseiten sind immer offen — auch ohne externen Kalender
•Die am 13.05. eingeführte Sperre, die Buchungsseiten geblockt hat, solange kein Kalender (Google / Outlook / CalDAV) verbunden ist, ist zurückgenommen.
•Alle 124 dadurch eingeschränkten Buchungsseiten sind ohne weiteres Zutun wieder offen.
•Sie können Zeitplanr weiterhin mit oder ohne externen Kalender betreiben. Buchungen werden in jedem Fall in Zeitplanr gespeichert, Sie und Ihre Gäste erhalten Bestätigungs-E-Mails, und Sie sehen alles unter /admin/bookings.
Warum: Unser Mandat ist eindeutig: Wir sind ein Buchungstool. Wenn Gäste und Gastgeber Termine buchen können, beide Bestätigungen bekommen und der Gastgeber alle Termine in Zeitplanr sieht — dann ist unsere Aufgabe erfüllt. Ob Sie zusätzlich einen externen Kalender verbinden, ist Ihre Entscheidung, nicht unsere Vorbedingung. Die Sperre hat dieses Mandat verletzt — sie hat ein Host-Problem (manche Hosts übersehen Buchungen, weil sie nur ihren externen Kalender pflegen) dadurch „gelöst", dass sie das Buchen für Gäste komplett verhindert hat. Das war der falsche Hebel.
Fehlerbehebung
Datumsbereich-Generator respektiert die wöchentliche Verfügbarkeit
•Im Termintyp-Modus „Bestimmte Tage" hat der Button „Datumsbereich hinzufügen" bisher pauschal alle Tage im Zeitraum eingefügt — auch Wochentage, die in der globalen Verfügbarkeit deaktiviert sind.
•Ab sofort werden Wochentage übersprungen, die in Ihrer wöchentlichen Verfügbarkeit auf „nicht verfügbar" stehen. Eine kleine Hinweiszeile zeigt an, wie viele Tage ausgelassen wurden.
•Bereits angelegte Einträge bleiben unverändert — wir filtern nicht rückwirkend, damit bewusst gesetzte Einzeltermine (z. B. Wochenend-Schulungen) erhalten bleiben.
Warum: Gemeldet von einem Host, dessen Buchungslink innerhalb eines Zeitraums auch Samstag und Sonntag anbot, obwohl beide Wochentage global deaktiviert waren. Die Logik war: einzelne ausgewählte Daten sind eine bewusste Ausnahme; ein per Bereich erzeugter Eintrag dagegen nicht.
Neue Funktion
Buchungen ohne externen Kalender annehmen
•Neuer Schalter unter /admin/integrations: Buchungsseite bleibt offen, auch wenn kein Google-/Outlook-/CalDAV-Kalender verbunden ist.
•Buchungen werden in diesem Modus ausschließlich bei Zeitplanr gespeichert und unter „Buchungen" verwaltet.
•Es werden keine Kalender-Einträge in Drittsystemen erstellt und keine externen Einladungen verschickt — E-Mail-Bestätigungen kommen ausschließlich von Zeitplanr.
Warum: Eine am 13.05. ausgerollte Schutzregel hatte die Buchungsseite für Hosts ohne verbundenen Kalender gesperrt, um stille Sync-Fehler zu vermeiden. Hosts, die bewusst keinen Drittkalender anbinden möchten (Datenschutz, geringere Drittsystem-Abhängigkeit), waren damit aber ausgeschlossen. Der Schalter macht den Opt-out explizit.
Fehlerbehebung
Buchungsseite blockiert, wenn Host keinen Kalender verbunden hat
•Sowohl /api/availability als auch /api/book lehnen Buchungen ab, wenn der Host weder Google, Outlook noch CalDAV verbunden hat.
•Statt eines leeren Slot-Pickers sehen Gäste einen klaren Hinweis, dass der Host die Kalender-Einrichtung noch nicht abgeschlossen hat.
Warum: Eine Untersuchung am 13.05. fand 10 Hosts mit ~100 zukünftigen Buchungen, die ausschließlich in unserer DB lagen und nirgends im Kalender des Hosts auftauchten. Hosts merkten das oft erst, wenn ein Gast vor verschlossener Tür stand. Wir schließen diese Lücke und benachrichtigen betroffene Hosts proaktiv.
Sicherheit
Zusätzliche Sicherheitsschicht im iCalendar-Feed (Row-Level Security)
•Der ICS-Feed läuft nun zusätzlich gegen einen RLS-erzwungenen Datenbank-Client.
•Selbst bei einem hypothetischen Token-Validierungsfehler würde PostgreSQL keine fremden Buchungen mehr zurückgeben.
•Einzelne aktive Feeds wurden vorsorglich rotiert.
Warum: Eine Nutzerin meldete am 08.05. fremde Termine in ihrem Apple Kalender. Der Audit zeigte: unser Feed liefert ihre Daten korrekt aus. Trotzdem haben wir defensiv eine zweite Schutzschicht eingezogen — bei Datenschutzthemen sind uns Belt + Suspenders wichtiger als minimaler Code.
Sicherheit
Kritischer Fix: iCalendar-Feed konnte fremde Buchungen ausliefern
•Token-Lookup im ICS-Feed wurde von einer Prisma-JSON-Path-Abfrage auf eine deterministische @unique-Spalte umgestellt.
•Alle bestehenden Tokens wurden migriert; betroffene Hosts wurden aufgefordert, ihre Feed-URL zu rotieren.
Warum: Die JSON-Path-Abfrage konnte unter PostgreSQL die falsche User-ID liefern, sodass fremde Buchungen im ICS-Feed eines anderen Hosts auftauchen konnten. Falls Sie Ihren ICS-Feed vor April 2026 in Apple Kalender eingerichtet haben, kann es lokal noch zwischengespeicherte Alteinträge geben — einmal das Abo entfernen und mit neuer URL wieder hinzufügen räumt sie weg.
Etwas unklar oder ein Fehler aufgefallen?
Schreiben Sie uns an info@zeitplanr.de — wir nehmen Hinweise zu Buchungs-, Datenschutz- und Sicherheitsthemen ernst und beantworten jede Rückmeldung persönlich.