events/tests
Padreug b55d6866d6
Some checks failed
lint.yml / fix: honour per-wave fiat when the organiser set an explicit rail list (pull_request) Failing after 0s
fix: honour per-wave fiat when the organiser set an explicit rail list
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.
2026-09-30 19:32:07 +02:00
..
__init__.py feat: code quality (#34) 2024-08-29 12:18:49 +02:00
test_capacity_guard.py fix(tickets): amount_tickets is the remaining count, stop subtracting sold 2026-09-27 22:25:01 +02:00
test_crud_ticket_email.py feat: let a user_id ticket carry an email, accept frontend_url 2026-09-06 19:53:05 +02:00
test_frontend_root.py feat: return buyers to the calling app after Stripe, branded QR endpoint 2026-09-06 19:53:05 +02:00
test_init.py feat: code quality (#34) 2024-08-29 12:18:49 +02:00
test_nostr_publish_pending.py feat(nostr): flag events whose NIP-52 publish didn't land 2026-09-26 23:45:47 +02:00
test_nostr_timestamp.py fix: publish NIP-52 events with monotonic created_at (#26) 2026-06-18 14:13:10 +02:00
test_promo.py Merge upstream v1.6.8 into the aio fork 2026-09-28 22:09:18 +02:00
test_promo_api.py feat(promo): enforce active + max_uses, validate endpoint, codes hidden from public 2026-09-13 18:43:34 +02:00
test_publish_active_wave.py fix: honour per-wave fiat when the organiser set an explicit rail list 2026-09-30 19:32:07 +02:00
test_publish_availability.py fix(nostr): always publish tickets_available, zero is not unlimited 2026-09-27 23:03:54 +02:00
test_publish_confirmation.py feat(nostr): confirm publishes against the relay's OK 2026-09-27 22:11:21 +02:00
test_ticket_email.py feat: attach a self-describing ticket card to the email (1.6.1-aio.10) 2026-09-08 16:40:25 +02:00
test_ticket_models.py fix: honour per-wave fiat when the organiser set an explicit rail list 2026-09-30 19:32:07 +02:00
test_ticket_qr.py feat: attach a self-describing ticket card to the email (1.6.1-aio.10) 2026-09-08 16:40:25 +02:00
test_wave_capacity_required.py fix: require a capacity on every ticket wave 2026-09-28 23:11:30 +02:00
test_wave_preservation_on_edit.py fix: keep ticket waves when a client edits an event without them 2026-09-29 08:12:09 +02:00
test_wave_transition_sweep.py feat(nostr): publish the active ticket wave, not the roll-up 2026-09-28 22:28:09 +02:00