Ticket waves never rendered in the organiser table #68
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/wave-chip-lnbits-global"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The expanded event row showed "Ticket waves" with a + button and an empty list, however many waves the event had. Reported from aio-demo, reproduced in a fresh incognito window — so not a caching artifact.
Cause
The chip built its label inline:
Vue resolves template expressions against the component instance, where the
LNbitsglobal is not in scope. So it threwand the entire
v-forrendered nothing. The promo-code chips beside it were unaffected, which is exactly what made this look like a data problem — the waves were always present in the response, on both the authenticated and public endpoints.That line arrived with the v1.6.8 merge. It is upstream's, and it is the only
LNbits.reference in any template in this extension —display.vueandticket.vuehave none. The convention here was already "format in a method"; the merge quietly broke it, and nothing caught that because the extension has no template-level test.Fix
waveSummary(eventId, wave)builds the label inindex.js, where the global is in scope. It also trims wave dates to the day for display:closing_datedefaults fromevent_end_dateand can carry a time, which was rendering as2026-12-09T16:00:00+01:00inside the chip.Verified
In a browser against a two-wave event, both chips render:
No TypeError. 133 tests pass; prettier clean (baseline checked in place first).
Worth noting for the next merge
This is a fourth distinct way the v1.6.8 merge went wrong in a spot the tests couldn't see — after the collided
_ticket_image_url, the duplicate/qrroute, and the explicit-rail-list short-circuit. All four shared a shape: upstream code that is correct for upstream behaving differently inside this fork's conventions.docs/rebase-playbook.mdcovers the first two as modes C and D; a template-scope check would be worth adding alongside them.Wants a
v1.6.8-aio.4— it is a visible defect in a released version, and organisers currently cannot see or edit any wave from the LNbits UI.The expanded event row showed "Ticket waves" with a + button and an empty list, however many waves the event had. Reported from aio-demo and reproduced in a fresh incognito window, so not a caching artifact. The chip built its label inline with `LNbits.utils.formatCurrency(...)`. Vue resolves template expressions against the component instance, where the `LNbits` global is not in scope, so the expression threw TypeError: Cannot read properties of undefined (reading 'utils') and the whole v-for rendered nothing. The promo-code chips beside it were unaffected, which is what made the list look like a data problem — the waves were always present in the response. That line arrived with the v1.6.8 merge: it is upstream's, and upstream is the only `LNbits.` reference in any template in this extension (display.vue and ticket.vue have none). So the convention here was already "format in a method", and the merge quietly broke it. `waveSummary` now builds the label in index.js, where the global is in scope. It also trims the day off wave dates for display — closing_date defaults from event_end_date and can carry a time, which was rendering as "2026-12-09T16:00:00+01:00" in the chip. Verified in a browser against a two-wave event: both chips render as "Primary wave - 2026-10-03 to 2026-11-02 - €30.00 - 50 tickets - 0 sold" with no TypeError.