Event finance
- Finance tab on the event page: P&L summary with a revenue-to-result
waterfall, costs and other income in one ledger, and the partner split
with payouts. Lifecycle stepper (Selling, Adding costs, Ready to close,
Finalized) with what is left to do; closing the books goes through a
checklist dialog that freezes the numbers.
- Expense modal shows only the fields each calculation type needs, a live
preview with the event's real counts, and a category suggested from the
description. Date inputs follow the UI language.
- Global Finance page: profit per event with outliers clipped and labelled,
and a "Ready to close" list of past events whose books are still open.
- Calculation service (integer PYG, basis points) with pinned regression
scenarios; PYG formatting centralised in lib/money with locale-aware
separators.
Event team permissions
- Per-event members with role presets and requireEventPermission; the
header stat "Confirmed" is relabelled "Not checked in yet", which is
what it counts.
Public sales state
- One sales state (online, door, sold out, ended, external, cancelled) for
the event page, listings and JSON-LD, with the door price and tenders
shown only while people can still pay at the door.
Frontend unit tests run with vitest (npm test in frontend/).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Most attendees arrive without their QR open, and taking money at the
door meant leaving the scanner for the event dashboard, where the Add
Ticket modal demanded an email and recorded no payment method. The
screen now leads with manual name search, keeps the camera one tap away
behind a fullscreen overlay, and creates and charges walk-ins inline.
Check-in and payment are one action: anything done here is born
confirmed, paid (or comp) and checked in through a single endpoint,
POST /api/events/:eventId/door-checkin. There are no confirm dialogs
anywhere, because they stall the queue; a ten-second Undo replaces
them, reversing exactly what the action changed via the undo state
recorded alongside its idempotency key. Writes fire in the background
with retries, so venue wifi never blocks the person at the door, and a
capacity limit only warns, since staff at the door are the authority.
Every write carries a client-generated idempotency key, inserted in the
same transaction as the writes it guards, so a double tap or a retry
after a timeout cannot produce a second ticket, payment or check-in.
Search runs entirely in memory over one preloaded list: names are
matched accent- and case-insensitively in both directions, per word,
prefix before substring, with a mostly-numeric query searching phone
digits so two people with the same name can be told apart.
Door money is recorded as payments.source 'door' plus payments.method
(cash, bitcoin, transfer or guest) while provider keeps its existing
value, so capacity counting, the stale-booking sweeps and the admin
payment lists are unaffected and revenue can still be split pre-sale
versus door. Bitcoin records the payment as made, on the same trust
model as cash, with no invoice generated; lib/doorPayments.ts is where
a real Lightning flow slots in later.
Also fixes the SQLite tickets DDL, which still created the pre-split
attendee_name column with NOT NULL email and phone. Only fresh
databases were affected -- existing ones were relaxed by later ALTERs
-- but on those, door walk-ins (and any other ticket) could not be
inserted at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Split oversized frontend API client, email service, and admin/booking pages into focused modules while preserving import surfaces, and add Redis-backed queues, stale booking cleanup, stronger auth, and scale deployment configs.
Co-authored-by: Cursor <cursoragent@cursor.com>
