feat(refunds): refund a booking from the Desk (backport #328)

[harshtandiya]

Backport of #328. Loom: https://www.loom.com/share/a0bfd08d12c648d3b55adb4144179ac6

The label-driven backport failed to cherry-pick f4990fe, so this is the same commit applied by hand.

Both conflicts were import blocks, and neither was about refunds — they came from teams (#312) being on develop and not here:

• buzz/api/checkin/services.py — develop imports NotPermitted and has_team_access. Kept main's imports and added only get_committed_tickets; main's CheckinService has no team gate and buzz/permissions.py does not exist on this branch.
• buzz/ticketing/doctype/event_booking/event_booking.py — develop imports get_event_team_settings. Dropped it and kept get_controller, the two refund helpers and RAZORPAY; main's send_booking_confirmation_email never used team settings.

Everything else applied clean: both doctype JSONs, event_booking.js, payments.py, hooks.py, the new doctype folders, and the tests.

Before this is any use on a deployed site

• The site needs a frappe/payments carrying feat(razorpay): refunds and a signature-verified refund webhook frappe/payments#248 — refund_payment and the refund webhook. Without it the first refund raises AttributeError on get_controller(...).refund_payment.
• bench migrate for the two new doctypes and the two allow_on_submit fields on Event Booking.
• Razorpay Settings needs a webhook secret, and the Razorpay dashboard a webhook for refund.processed and refund.failed.

Verification

Compile and ruff check clean on this branch, with no develop-only references left behind. The suites were not re-run locally — the dev site carries develop's schema — so CI is the first real run here. The identical code passes 29 refund / 9 check-in / 40 booking / 28 ticket-API tests on develop.

[greptile-apps]

Greptile Summary

This PR adds Desk-initiated Razorpay refunds for event bookings, including webhook reconciliation and ticket cancellation after settlement.

• Adds refund records, booking refund status and amount tracking, and per-ticket refund associations.
• Adds a System Manager refund dialog and server-side validation for amount, ticket ownership, and prior check-in.
• Handles processed and failed refund notifications, updates booking state, and submits ticket cancellation requests.
• Prevents check-in while a ticket is attached to a committed refund.

Confidence Score: 4/5

The refund initiation path should be made atomic or idempotent before merging because concurrent requests or a post-gateway failure can refund more than the booking total.

The balance check only observes persisted refund rows, while the irreversible Razorpay call happens before the new row is recorded, leaving both a concurrency window and an external-success/local-failure window.

Files Needing Attention: buzz/ticketing/doctype/event_booking/event_booking.py

Important Files Changed

Filename	Overview
buzz/ticketing/doctype/event_booking/event_booking.py	Implements refund calculation and initiation, but the external refund occurs without atomic balance reservation or idempotency protection.
buzz/payments.py	Parses refund notifications, resolves their booking payment, deduplicates records by gateway refund ID, and applies gateway state.
buzz/ticketing/doctype/event_booking_refund/event_booking_refund.py	Tracks committed refunds, updates aggregate booking status, and initiates ticket cancellation after successful settlement.
buzz/ticketing/doctype/event_booking/event_booking.js	Adds the Desk refund workflow and renders refund history with constrained or escaped persisted values.
buzz/api/checkin/services.py	Rejects tickets held by committed refunds and normalizes numeric payment names for the response schema.
buzz/ticketing/doctype/ticket_cancellation_request/ticket_cancellation_request.py	Propagates permission bypass to document cancellation so authenticated webhook jobs can complete settled-refund cancellations.

Prompt To Fix All With AI

### Issue 1
buzz/ticketing/doctype/event_booking/event_booking.py:437
**Refund balance is not reserved**
If two refund requests for one booking overlap, both validate against the same persisted balance and call Razorpay before either refund is recorded, causing the customer to receive more than the booking total. A successful gateway call followed by a failed local insert similarly leaves the balance available for another refund.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat(refunds): refund a booking from the..." | Re-trigger Greptile}

[greptile-apps]

Refund balance is not reserved

If two refund requests for one booking overlap, both validate against the same persisted balance and call Razorpay before either refund is recorded, causing the customer to receive more than the booking total. A successful gateway call followed by a failed local insert similarly leaves the balance available for another refund.

Prompt To Fix With AI

This is a comment left during a code review.
Path: buzz/ticketing/doctype/event_booking/event_booking.py
Line: 437
Comment:
**Refund balance is not reserved**
If two refund requests for one booking overlap, both validate against the same persisted balance and call Razorpay before either refund is recorded, causing the customer to receive more than the booking total. A successful gateway call followed by a failed local insert similarly leaves the balance available for another refund.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.