You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mechanism is implemented in #64 (draft); the UX half of your issue isn't, so flagging both.
What exists:
An offer rule with "requires a ticket ID" + source credit + "move my ticket", configured per event in the promo dialog.
Credit is based on TicketExtra.paid_value — what the ticket actually cost, not its ticket type's list price — so a chain of upgrades (A→B→C) can't inflate its own value.
Credit is capped at the target ticket's price: if the difference is zero or negative the upgrade is free, never a payout.
move voids the source ticket and releases its seat when the upgrade is paid; both tickets record the link (upgraded_from / upgraded_to).
Cross-currency upgrades are blocked, as are already-consumed, deactivated and refunded source tickets.
POST /maintenance/backfill-paid-values reconstructs paid_value for tickets sold before that field existed, so historic tickets can be upgraded too.
What's missing — your "UX flow should make it obvious":
The buyer has to type <their ticket ID>, <offer code> into the same comma-separated promo box used for ordinary discounts. Nothing on the event page or on their ticket tells them an upgrade is available or that this is how to claim it.
The buyer's ticket page shows the QR and a copy-link button but never prints the ticket ID as text, so getting the ID means decoding the QR yourself.
Ownership is possession-based: the ticket ID is the bearer token, so anyone holding it can spend the upgrade.
Proposal: keep the promo machinery as-is and add a small "Upgrade this ticket" block on the ticket page that lists the offers matching that ticket's type, shows the computed difference, and pre-fills the ticket ID — plus print the ticket ID as text. Happy to take that as follow-up work if the direction's agreed.
Activity
dadofsambonzuki commentedon Oct 6, 2026
The mechanism is implemented in #64 (draft); the UX half of your issue isn't, so flagging both.
What exists:
TicketExtra.paid_value— what the ticket actually cost, not its ticket type's list price — so a chain of upgrades (A→B→C) can't inflate its own value.movevoids the source ticket and releases its seat when the upgrade is paid; both tickets record the link (upgraded_from/upgraded_to).POST /maintenance/backfill-paid-valuesreconstructspaid_valuefor tickets sold before that field existed, so historic tickets can be upgraded too.What's missing — your "UX flow should make it obvious":
<their ticket ID>, <offer code>into the same comma-separated promo box used for ordinary discounts. Nothing on the event page or on their ticket tells them an upgrade is available or that this is how to claim it.Proposal: keep the promo machinery as-is and add a small "Upgrade this ticket" block on the ticket page that lists the offers matching that ticket's type, shows the computed difference, and pre-fills the ticket ID — plus print the ticket ID as text. Happy to take that as follow-up work if the direction's agreed.