Repository navigation
One-time scheduling invitations for ticketing/CRM integrations (epic) #92
Description
From discussion #47 (KitKat31337, Zammad workflow). Full design in the discussion.
Concept: a first-class scheduling-invitation object separate from event type and booking. Event types stay reusable defaults; the invitation snapshots authorized per-request overrides (duration, host set reusing required/rotation/optional roles, date window), plus generic external {system, reference, url} fields and delivery: external|calnode mode.
Why core, not a bridge: the slot engine must understand effective duration/hosts/window before offering a time. Temp event types per ticket would work technically but clutter config and get the slot math wrong.
Incremental slice agreed in the discussion:
- Invitation records + opaque single-use expiring tokens (hashed at rest, same bar as
booking_manage_tokens) - Duration override (needs min/max/increment on event types — durations are fixed today)
- Fixed-host restriction (snapshot, no event-type mutation)
- Server-enforced date window (slots + booking creation, never browser-only)
- Webhook enrichment (
scheduling_invitation.*+booking.createdcarrying invitation + external ref)
Deferred: verification-code mode, token replacement, atomic-claim hardening beyond the single-connection serialization we already get.
Author offered testing with M365/Teams/Zammad. No timeline committed.
Discussion: #47
Activity
pullfrog commentedon Sep 22, 2026
KitKat31337 commentedon Sep 25, 2026
I have not really done much in Go, but am happy to contribute to this as well as the testing.
shockalotti commentedon Sep 27, 2026
No worries. Go for it. Go is awesome. Shout out if you have question.
shockalotti commentedon Sep 29, 2026
@KitKat31337 great to have you contributing, not just testing. Two threads to pull: the epic slices are yours to start whenever ready (slice 1 - invitation records + tokens - is the natural first PR), and the #99 Microsoft fix still needs its end-to-end proof. You're the only one here with two M365 accounts behind it - connecting the second alongside the first on current main would close that loop. Shout if anything in the codebase is unclear.
KitKat31337 commentedon Sep 29, 2026
Understood.
@shockalotti
Is this something you still want on my fork, or somewhere where we can collaborate? I am happy to connect via something like signal/discord if you like.
I have been at misc business events late the last several days, but will get to these soon.
shockalotti commentedon Sep 30, 2026
Fork plus PRs here is the way - keeps everything reviewable in one place. And I'd keep the design discussion on the issues rather than moving to chat: async suits the business-events schedule better anyway, and the next person with a Zammad setup benefits from reading the whole thread.
No rush on timing. #99 verification first when you get a window (clean test env, both accounts side by side), then slice 1 whenever. Shout here if the codebase fights you.
feat(invitation): add scheduling snapshots and availability