One-time scheduling invitations for ticketing/CRM integrations (epic) #92
Description
Activity
I have not really done much in Go, but am happy to contribute to this as well as the testing.
No worries. Go for it. Go is awesome. Shout out if you have question.
@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.
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.
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.
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 anddelivery: external|calnodemode.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:
booking_manage_tokens)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