Reported from aio-demo: an event with fiat enabled, Card offered at
checkout, and the purchase refused with "Fiat payments are not enabled
for this ticket wave."
`effective_payment_methods` returned the organiser's explicit
`extra.payment_methods` list before ever consulting the wave:
explicit = list(...)
if explicit:
return explicit # <- the wave never got a look in
So the `wave` argument I added for #61 did nothing in the common case.
The webapp always sets `extra.payment_methods` from its payment-method
checkboxes, which means the explicit path is the normal one, not the
exception — three layers then disagreed:
- the NIP-52 tag advertised `tickets_payment_methods: lightning,fiat`
while omitting `tickets_allow_fiat`, contradicting itself
- the checkout rendered a Card button
- `api_ticket_create`, the only wave-aware check, refused the purchase
Asking about a specific wave means asking what a buyer can actually use
for it, so a rail that wave cannot honour is now dropped. The
event-level question (no wave) still reports every rail the organiser
enabled — that is what `/republish-all` and the admin views want.
Fiat-only rails on a non-fiat wave now yield an empty list, which is
honest: nothing is purchasable from that wave.
5 tests, including both publisher shapes with an explicit list — the
case that actually bit, and which the #61 tests missed because their
fixtures left `payment_methods` empty. 133 pass.
Does not fix the data on events already created through the webapp:
their waves were saved with `allow_fiat` unset, so those waves genuinely
cannot take fiat until toggled. That is aiolabs/webapp's side.
Since upstream v1.6.8 price, currency and inventory belong to time-boxed
ticket waves, and the event-level fields `sync_event_ticket_waves`
derives are the PRIMARY wave's price/currency and the SUM of every
wave's stock. The NIP-52 publisher read those, so as soon as an
organiser created a second wave the public card would advertise the
early-bird price after early bird closed and count stock in waves that
had not opened. Refs #61.
`build_nip52_event` now describes the wave a buyer can actually buy
from:
- several waves can be open at once, and a publisher has no one to ask
which one the buyer wants (the purchase endpoint errors with "Please
select a ticket wave"), so it advertises the CHEAPEST open wave — the
price a buyer is able to obtain. Deviation recorded in
docs/upstream-candidates.md.
- with no open wave, `tickets_available` is 0 and never omitted:
omission used to mean "unlimited", which #34/#62 removed as a concept.
- `tickets_payment_methods` is scoped to the advertised wave too. It was
derived from `event.allow_fiat` — the primary wave's — so it could
offer a fiat rail while `tickets_allow_fiat` was absent and the
purchase endpoint would refuse it. They are the same fact and now come
from the same place.
Wave boundaries are time-driven, and every republish we have is
sale-driven, so nothing fires when early bird ends at midnight. Rather
than add a scheduler, a publish records which wave it advertised
(`nostr_published_wave_id`, m004) and the reconciliation sweep compares
that against the wave that would be advertised now, setting
`nostr_publish_pending` on a mismatch — reusing the existing retry path.
NULL means "never published", which the sweep leaves alone so an upgrade
does not republish the whole table on first boot.
The selection rule lives in `models.advertised_ticket_wave` so the
publisher and the drift detector cannot disagree about what is on the
relay.
17 new tests; 114 pass. ruff, black, prettier clean; mypy error set
still identical to HEAD's baseline.
