feat(booking): acknowledge offline bookings before verification

[harshtandiya]

What changed

Closes #387.

An offline booking sits as a draft until an Event Manager verifies the payment, but nothing told the booker that. No email went out until approval, and a guest was shown the generic success panel claiming their tickets had already been sent — while the booking had no tickets at all.

Now the booking sends an acknowledgement the moment it is created: booking reference, event and participant details, offline method and amount, and a plain statement that the tickets are not confirmed yet and a separate confirmation will follow. The wording is overridable per event through a new Offline Payment Acknowledgement Email Template field; the existing Send Booking Confirmation Email check gates both booking emails, so there is no second toggle to keep in sync and no new Team Settings default.

The confirmation email's recipient resolution, argument building and send now live in shared methods both emails call, so the two cannot drift.

For guests the inline panel gains a pending variant carrying the booking reference — guests have no session to open /bookings/<name> with. Logged-in users already landed on the "Payment Confirmation Pending" booking page and are untouched, as is everything after approval: payment marked paid, booking submitted, tickets generated, existing confirmation and ticket emails sent.

Second commit is a bug the render turned up: ticket types autoname to integers while the Link field hands back a string, so the title map never matched and every attendee row in the booking confirmation email has printed the ticket type's id since it shipped.

Not in scope, all pre-existing: no email on rejection, approval still lives only in Desk, and offline bookings still record no Event Payment so they cannot be refunded.

Demo

Testing

• TestOfflineAcknowledgementEmail (9 cases): recipient and reference fields, built-in template, args payload, per-event template override, the confirmation template must not leak in, event toggle off, Administrator/Guest skipped, plus one test that actually renders the new HTML — every other email test mocks frappe.sendmail, so a broken Jinja tag would otherwise ship.
• test_offline_booking_acknowledges_then_confirms: creation sends exactly one mail and no tickets; approval then sends the confirmation and generates them.
• bookingSuccessRedirect.test.ts: guest + offline is pending, guest without offline is not, logged-in offline unchanged.
• Full suite green on a local site (600 + 69 Python, 104 dashboard unit tests); manual run of the guest offline flow end to end, with the acknowledgement landing in the Email Queue.

[github-actions]

✅ UI Demo Check — a screenshot or demo is attached.

[greptile-apps]

Greptile Summary

The PR adds a pre-verification acknowledgement for offline bookings, configurable per event, and introduces a dedicated pending result for guest checkout.

• Shares recipient resolution, template rendering, and email arguments between acknowledgement and confirmation messages.
• Displays the pending booking reference to guests while preserving the existing signed-in flow.
• Corrects ticket-type title lookup when numeric document names are represented as strings.

Confidence Score: 4/5

The PR should not merge until the guest pending panel stops promising a verification email when booking emails are disabled.

The server deliberately suppresses acknowledgement and confirmation messages when the event disables booking emails, but the guest-offline success panel still unconditionally tells the guest that an email will follow verification.

Files Needing Attention: dashboard/src/components/BookingForm.vue

Important Files Changed

Filename	Overview
buzz/api/booking/services.py	Sends the new acknowledgement after persisting an offline booking while keeping email failure non-fatal.
buzz/ticketing/doctype/event_booking/event_booking.py	Adds the acknowledgement sender and consolidates recipient resolution, rendering arguments, and dispatch for both booking emails.
buzz/events/doctype/buzz_event/buzz_event.json	Adds the event-level acknowledgement-template override under the existing booking-email toggle.
buzz/templates/emails/offline_booking_acknowledgement.html	Provides the built-in pending-payment acknowledgement with booking, attendee, and amount details.
dashboard/src/components/BookingForm.vue	Adds the guest pending-verification panel, but its unconditional email promise remains inconsistent with events that disable booking emails.
dashboard/src/utils/bookingSuccessRedirect.ts	Distinguishes guest offline responses as an inline pending result while leaving signed-in routing unchanged.

_{Reviews (2): Last reviewed commit: "chore(booking): tidy offline acknowledge..." | Re-trigger Greptile}

[greptile-apps]

Disabled email still promised

When a guest makes an offline booking for an event with booking emails disabled, this panel still promises an email after verification, but get_booking_email_recipient suppresses that confirmation, leaving the guest waiting for an email that will never be sent.

Knowledge Base Used: Booking checkout and payment collection

Prompt To Fix With AI

This is a comment left during a code review.
Path: dashboard/src/components/BookingForm.vue
Line: 81-83

Comment:
**Disabled email still promised**

When a guest makes an offline booking for an event with booking emails disabled, this panel still promises an email after verification, but `get_booking_email_recipient` suppresses that confirmation, leaving the guest waiting for an email that will never be sent.

**Knowledge Base Used:** [Booking checkout and payment collection](https://app.greptile.com/bwh-tech/-/custom-context/knowledge-base/bwhtech/buzz/-/docs/booking-checkout.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[harshtandiya]

Going to update email templates in a different PR

[github-actions]

Backport failed for main, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin main
git worktree add -d .worktree/backport-388-to-main origin/main
cd .worktree/backport-388-to-main
git switch --create backport-388-to-main
git cherry-pick -x 013589655dda0705ee5b922e617ed9ada4f34882