Ticket waves follow the event's fiat setting #179

Merged

padreug merged 2 commits from fix/wave-fiat-inheritance into dev

2026-09-30 20:30:49 +00:00

padreug commented

2026-09-30 17:40:03 +00:00

Owner

Reported from aio-demo: event with card enabled, Card offered at checkout, purchase refused with "Fiat payments are not enabled for this ticket wave."

Two causes, both introduced with wave support in #176.

1. Waves never carried the fiat flag

newWaveRow set id, title, dates, currency, capacity and price — not allow_fiat. Fiat is a per-wave opt-in in the extension, so every wave the webapp created silently refused card payments however the event-level toggle was set.

Confirmed against the live instance — the reported event:

primary        allow_fiat: True    (written by applyFormToPrimaryWave)
Earliest Bird  allow_fiat: False   fiat_currency: GBP
Early Bird     allow_fiat: False   fiat_currency: GBP
Just a bird    allow_fiat: False   fiat_currency: GBP

The primary wave was right because applyFormToPrimaryWave writes the form values into it; the three added waves were not. GBP is the backend's TicketWave default, since the webapp never sent a currency for them either.

The Card checkbox now governs every wave on save — ticking it enables fiat on all of them, unticking disables it on all of them, and each settles in the event's fiat currency rather than whatever it happened to hold. The webapp offers exactly one control for fiat, so one control decides it.

An earlier revision of this branch added a per-wave switch instead. That was wrong and has been removed: with the event-level setting applied on save it would be silently overwritten, and a control that disagrees with what gets stored is worse than none.

The trade-off, stated plainly: a per-wave fiat setting made in the LNbits admin (which does have that control) is overwritten next time the event is saved from the webapp. Acceptable while the webapp has no way to represent one — and now deliberate rather than accidental, which the previous behaviour was not.

2. The rail list ignored the wave

effectivePaymentMethods returned the organiser's explicit payment_methods before consulting anything else, so the Card button appeared regardless of what the wave could take. That list is event-level while fiat is per-wave, and the webapp always sets it — so the explicit path is the normal one, not the exception.

The wave is a separate argument rather than folded into allowFiat: that one is the event's legacy flag and means something different. Conflating them broke two existing tests, correctly — which is how the design fault surfaced. Mirrors the backend's effective_payment_methods(event, wave) (aiolabs/events#67).

Tests

11 new, including that an unset wave flag reads as no-fiat (how the backend reads it), that the event-level question stays unfiltered, that the event's fiat currency overwrites a stale per-wave one, and that nothing else about a wave is disturbed. 83 pass; vue-tsc, prettier and the production build clean.

Existing events

Waves already saved with allow_fiat unset stay wrong until the event is saved again from the webapp — the data is genuinely wrong, not just displayed wrong. Re-saving now fixes every wave at once. Pairs with aiolabs/events#67.

Reported from aio-demo: event with card enabled, Card offered at checkout, purchase refused with **"Fiat payments are not enabled for this ticket wave."** Two causes, both introduced with wave support in #176. ## 1. Waves never carried the fiat flag `newWaveRow` set id, title, dates, currency, capacity and price — **not `allow_fiat`**. Fiat is a per-wave opt-in in the extension, so every wave the webapp created silently refused card payments however the event-level toggle was set. Confirmed against the live instance — the reported event: ``` primary allow_fiat: True (written by applyFormToPrimaryWave) Earliest Bird allow_fiat: False fiat_currency: GBP Early Bird allow_fiat: False fiat_currency: GBP Just a bird allow_fiat: False fiat_currency: GBP ``` The primary wave was right because `applyFormToPrimaryWave` writes the form values into it; the three added waves were not. `GBP` is the backend's `TicketWave` default, since the webapp never sent a currency for them either. **The Card checkbox now governs every wave on save** — ticking it enables fiat on all of them, unticking disables it on all of them, and each settles in the event's fiat currency rather than whatever it happened to hold. The webapp offers exactly one control for fiat, so one control decides it. An earlier revision of this branch added a *per-wave* switch instead. That was wrong and has been removed: with the event-level setting applied on save it would be silently overwritten, and a control that disagrees with what gets stored is worse than none. **The trade-off, stated plainly:** a per-wave fiat setting made in the LNbits admin (which does have that control) is overwritten next time the event is saved from the webapp. Acceptable while the webapp has no way to represent one — and now deliberate rather than accidental, which the previous behaviour was not. ## 2. The rail list ignored the wave `effectivePaymentMethods` returned the organiser's explicit `payment_methods` before consulting anything else, so the Card button appeared regardless of what the wave could take. That list is event-level while fiat is per-wave, and the webapp always sets it — so the explicit path is the normal one, not the exception. The wave is a **separate argument** rather than folded into `allowFiat`: that one is the event's legacy flag and means something different. Conflating them broke two existing tests, correctly — which is how the design fault surfaced. Mirrors the backend's `effective_payment_methods(event, wave)` (aiolabs/events#67). ## Tests 11 new, including that an unset wave flag reads as no-fiat (how the backend reads it), that the event-level question stays unfiltered, that the event's fiat currency overwrites a stale per-wave one, and that nothing else about a wave is disturbed. 83 pass; vue-tsc, prettier and the production build clean. ## Existing events Waves already saved with `allow_fiat` unset stay wrong until the event is saved again from the webapp — the data is genuinely wrong, not just displayed wrong. Re-saving now fixes every wave at once. Pairs with aiolabs/events#67.

padreug added 1 commit

2026-09-30 17:40:03 +00:00

fix(events): ticket waves inherit the event's fiat setting 4ce36598ce

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.

padreug added 1 commit

2026-09-30 19:44:00 +00:00

fix(events): the Card checkbox governs fiat on every wave 773d87d35b

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.

padreug changed title from ~~Ticket waves inherit the event's fiat setting~~ to Ticket waves follow the event's fiat setting

2026-09-30 19:44:17 +00:00

padreug merged commit c323875ec9 into dev

2026-09-30 20:30:49 +00:00

padreug deleted branch fix/wave-fiat-inheritance

2026-09-30 20:30:49 +00:00

padreug referenced this pull request from a commit

2026-09-30 20:30:51 +00:00

Merge pull request 'Ticket waves follow the event's fiat setting' (#179) from fix/wave-fiat-inheritance into dev

padreug referenced this pull request from a commit

2026-10-03 05:51:50 +00:00

chore(release): v1.6.8-aio.3