[dadofsambonzuki]

Summary

Major rewrite: multi-ticket basket checkout, ticket types, ticket-scoped promo offers, event-level payment methods, fiat via core providers, ticket deactivation, and migrations for the new promo/basket schema.

Changes

• Ticket types — multiple ticket tiers with pricing, availability windows and max limits

• Multi-ticket basket checkout — buy several tickets of different types in one transaction

• Promo codes — classic — percentage or fixed discounts, add/edit via inline chip UI, deactivated codes shown with strikethrough

• Promo codes — ticket-scoped offers — ticket-scoped promo rules are now identified by PromoCode.source alone (PromoSource: require_ticket, event_ids, ticket_type_ids, move, credit), each with its own optional offer code. This replaces the old type / TICKETID encoding, which could only express one such rule per event; an event can now carry several ticket rules (an upgrade rule, a bring-a-friend rule, ...) and still distinguish them. Pricing and reservation share a single resolver (_resolve_ticket_rules) so they cannot disagree about which rule owns a ticket. Rule ranking is named offer code > codeless rule > un-named coded rule, so a typed offer code is never ignored. max_uses is now enforced on ticket rules. Rejections carry a reason (ticket_count_not_eligible, promo_uses_exhausted, ticket_needs_offer_code, ticket_out_of_scope, ticket_already_used, ticket_redemptions_exhausted, currency_mismatch, ...) and are deduplicated per token; checkout surfaces both pending (awaiting a ticket id) and rejections

• Promo codes — add-on ticket grants — the other half of the offer-code axis: a rule can GRANT tickets of another type instead of discounting (PromoCode.grants = PromoGrant{ticket_type_id, per_source}). A discount cannot express a free GATED add-on, because with no discount to withhold an unsatisfied source condition enforces nothing. An add-on may only be added while a qualifying source ticket is present — in the basket itself, or presented by id — never beyond per_source × admits per source ticket, and never past the add-on type's cap. TicketType.extra.admits (default 1) records how many people a ticket admits, so a Family ticket is worth four add-ons where a Single is worth one; it lives in the JSON column, so no migration is needed. Grant rules are excluded from the discount engine but still pair, so the reservation / redemption / finalize machinery applies unchanged and a holder cannot re-claim. Enforced entirely server-side in _validate_addon_items, with the cap counted from ticket rows because ticket_types.sold under-counts (tickets that arrive already paid skip set_ticket_paid's increment). 15 tests in tests/test_addon.py. Sources may live in another event — a Freedom Fest ticket can claim a Bitfest screening seat — in which case their admits is resolved by looking the type up, rather than defaulting to one. Cap may also SPAN events: types carrying the same extra.cap_group share one cap, summed across the group, because one pool of seats can be sold from more than one event's checkout (two add-on types with their own max_tickets would otherwise mean two pools). 15 tests in tests/test_addon.py.

• Buyer checkout no longer uppercases the promo input, which had been destroying case-sensitive ticket IDs. Offer codes themselves remain case-insensitive

• Upgrade semantics — credit basis is TicketExtra.paid_value, upgrades are capped at free, a move rule voids the source ticket and releases its seat, require_ticket rules can cross events on the target event, cross-currency is blocked

• Migrations — m010_promo_source_axis normalises BOTH the legacy type and the interim source.kind to require_ticket and is re-runnable over either revision; m011_basket_total adds the Basket.total column that the model declared and crud.create_basket wrote but no migration created (without it every basket INSERT failed with "table events.baskets has no column named total" — a checkout 500)

• Maintenance endpoint — POST /maintenance/backfill-paid-values reconstructs TicketExtra.paid_value for tickets sold before the field existed, from their basket, falling back to the ticket type price; idempotent

• Payment methods per event — LN, onchain, fiat checkboxes with per-method wallet selection; checkout retries with remaining methods if one fails

• Fiat via core — fiat provider credentials from LNbits core settings, authorized per user

• Satspay charge ID linked to tickets — hyperlinked column in the admin tickets table

• Ticket deactivation — toggle in the admin table, deactivated badge on the public page, rejected at registration

• Bulk email — resend all tickets, custom message to attendees, with confirmation dialog

• Admin email — per-event admin notification email for ticket sales

• Simplified basket — single email + optional name at basket level; batched email per buyer

• UI — offer-code input plus a require_ticket toggle, with the per-ticket limits shown only when a ticket is required; QR/button layout and field alignment fixes across dialogs

• i18n — new keys in en, es and de

• Ticket-type availability is derived — ticket_types.sold is computed on read from the ticket rows (paid, not refunded, not deactivated) rather than trusted from a stored column that set_ticket_paid under-maintained (a ticket arriving already paid, e.g. an import, never ran the increment; a type with 12 paid rows read 0). The checkout's availability filter, its remaining calculation and the public display's cap filter all read the same derived value, so a sold-out type is no longer offered and caps cannot leak.

• Grant rules are self-describing in the admin — a grant has no code and no discount, so its chip used to render as a blank - and neither dialog showed the ticket it adds, leaving the rule looking like a purposeless "requires ticket id" entry. The chip now names the granted ticket (→ Bitflix …) and both dialogs badge the granted type while disabling the target-scope and discount controls, neither of which applies to a grant. promo_grants_label / promo_grants_hint in en/es/de.

• Grant rules, offer names and ticket-type facts are authorable in the admin — an "Adds tickets instead of a discount" toggle (which forces the source gate and clears any discount, mirroring the API coercion) with the ticket to add and per_source; an offer title so a code-less rule stays identifiable in the promo list; and admits / cap_group on the ticket type dialog. Also fixes a silent config loss: the ticket type dialog rebuilt extra from scratch while its data carried no extra key, so saving ANY ticket type dropped admits and cap_group.
  See individual commits for detailed changes.