Follows the inheritance commit: seeding only NEW waves still left the
ones already on an event refusing card payments, and gave the organiser
no single place to change that.
The extension treats fiat as a per-wave opt-in, but the webapp offers
exactly one control for it — the event-level Card checkbox. So that
checkbox now governs every wave on save: ticking it enables fiat on all
of them, unticking disables it on all of them, and each wave settles in
the event's fiat currency rather than whatever it happened to hold.
Waves created before this carry the backend's "GBP" default even on a
EUR event, which is what demo showed.
Removes the per-wave switch added a commit ago. With the event-level
setting applied on save it would be overwritten silently, and a control
that disagrees with what gets stored is worse than no control.
The trade-off, stated plainly: a per-wave fiat setting made in the
LNbits admin is overwritten the next time the event is saved from the
webapp. That is acceptable while the webapp has no way to represent one
— and it is deliberate rather than accidental, which the previous
behaviour was not.
4 tests: fiat on and off across every wave, the event currency winning
over a stale per-wave one, and everything else about each wave left
alone. 83 pass; vue-tsc, prettier and the production build clean.
Reported from aio-demo: an event with card enabled, Card offered at
checkout, and the purchase refused with "Fiat payments are not enabled
for this ticket wave."
Two causes, both introduced with wave support in #176.
**New waves never carried the flag.** `newWaveRow` set id, title, dates,
currency, capacity and price — not `allow_fiat`. Fiat is a per-wave
opt-in, so every wave the webapp created silently refused card payments
however the event-level toggle was set. The editor now seeds new waves
from the event, the way the LNbits admin dialog seeds one from the
primary wave, and exposes a per-wave switch so an existing wave can be
corrected — the LNbits admin has had that control all along, which is
why the event looked fiat-enabled there while its waves were not.
**The rail list ignored the wave.** `effectivePaymentMethods` returned
the organiser's explicit `payment_methods` before consulting anything
else, so the card button appeared regardless. That list is event-level
while fiat is per-wave, and the webapp always sets it, so the explicit
path is the normal one rather than the exception.
The wave is now a separate argument rather than being folded into
`allowFiat`: that one is the event's legacy flag and means something
different, and conflating them broke two existing tests — correctly,
which is how the design fault showed up. Matches the backend's
`effective_payment_methods(event, wave)` (aiolabs/events b55d686).
7 tests, including that an unset wave flag reads as no-fiat (how the
backend reads it) and that the event-level question stays unfiltered.
79 pass; vue-tsc, prettier and the production build clean.
Needs the matching events release to be deployed for the published
NIP-52 tags to agree; the webapp half stands alone.
