Changelog

What we change in Zeitplanr, when — and why. An open record for hosts and guests.

  1. New feature

    Custom slot interval (Taktung)

    • New optional control per event type under "Advanced": decouple the cadence of offered start-times from the meeting duration.
    • Example: 60-minute meeting + interval "Every 30 minutes" → guests see 10:00, 10:30, 11:00, 11:30 … Once one slot is booked, overlapping slots automatically disappear.
    • Works in both modes: "Weekly schedule" and "Specific days".
    • Default: "Default (= meeting duration)" — every existing event type stays unchanged, no action needed.
    Why: Direct response to user feedback: a host wanted to offer 60-minute meetings on a 30-minute cadence and was getting it via a clever overlapping-window hack on the weekly availability — which didn't carry over to "specific days" mode. The new setting makes the hack unnecessary and works identically across both scheduling modes.
  2. Policy

    Booking pages stay open — with or without an external calendar

    • The May 13 gate that blocked booking pages when no calendar (Google / Outlook / CalDAV) was connected is reverted.
    • All 124 booking pages that had been restricted are open again — no action needed.
    • You can keep running Zeitplanr with or without an external calendar. Bookings are saved in Zeitplanr either way, you and your guests get confirmation emails, and everything is visible under /admin/bookings.
    Why: Our mandate is simple: we are a booking tool. If guests and hosts can book meetings, both get confirmations, and the host sees every booking inside Zeitplanr — our job is done. Whether you also connect an external calendar is your choice, not our precondition. The gate violated that mandate — it "solved" a host-side awareness problem (some hosts miss bookings because they only check their external calendar) by blocking guests from booking entirely. Wrong lever.
  3. Bug fix

    Date-range generator now respects weekly availability

    • In event-type mode "specific days", the "Add date range" button used to insert every day in the interval — including weekdays disabled in your global availability.
    • It now skips weekdays your global weekly availability marks as unavailable. A small notice tells you how many days were skipped.
    • Existing overrides are left untouched — we do not retroactively filter so that deliberately scheduled single dates (e.g. weekend trainings) remain bookable.
    Why: Reported by a host whose booking link offered Saturday and Sunday inside a date range although both weekdays were globally disabled. The model: individually picked dates are deliberate exceptions; rows generated en-masse by a range are not.
  4. New feature

    Accept bookings without an external calendar

    • New toggle under /admin/integrations: your booking page stays open even without a Google / Outlook / CalDAV connection.
    • In this mode bookings live only inside Zeitplanr and are managed under "Bookings".
    • No calendar events are created in third-party systems and no external invitations go out — email confirmations come from Zeitplanr only.
    Why: A safeguard shipped on May 13 had locked the booking page for hosts without any connected calendar to prevent silent sync failures. Hosts who deliberately avoid third-party calendars (privacy, fewer external dependencies) were caught in the gate. This toggle makes the opt-out explicit.
  5. Bug fix

    Booking page blocks when host has no calendar connected

    • Both /api/availability and /api/book refuse bookings when the host has neither Google nor Outlook nor CalDAV connected.
    • Instead of an empty slot picker guests now see a clear notice that the host has not finished calendar setup.
    Why: An audit on May 13 found 10 hosts with ~100 future bookings sitting only in our DB and nowhere in the host's calendar. Hosts often noticed only when a guest arrived to a missing meeting. We close the gap and proactively notify the affected hosts.
  6. Security

    Additional security layer in the iCalendar feed (Row-Level Security)

    • The ICS feed now also runs through an RLS-enforced database client.
    • Even in the case of a hypothetical token-validation bug, PostgreSQL itself would refuse to return another host's bookings.
    • A small number of active feeds were rotated as a precaution.
    Why: A user reported foreign appointments in her Apple Calendar on May 8. The audit showed our feed serves her data correctly. We still added a second defensive layer — for privacy topics we prefer belt + suspenders over minimal code.
  7. Security

    Critical fix: iCalendar feed could deliver foreign bookings

    • ICS feed token lookup switched from a Prisma JSON-path query to a deterministic @unique column.
    • All existing tokens were migrated; affected hosts were advised to rotate their feed URLs.
    Why: The JSON-path query could return the wrong user ID on PostgreSQL, leaking bookings into another host's ICS feed. If you set up your ICS feed in Apple Calendar before April 2026, locally cached old entries may still be visible — remove the subscription and re-add it with the new URL to clear them.

Something unclear, or spotted a problem?

Email us at info@zeitplanr.de — we take booking, privacy, and security reports seriously and reply to every message personally.