MichilisandClaude Opus 5
e296e80e48
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>
39 lines
1.1 KiB
TypeScript
39 lines
1.1 KiB
TypeScript
// Barrel for the frontend API client. Consumers import from `@/lib/api`.
|
|
export type { ApiError } from './client';
|
|
export * from './types';
|
|
|
|
export { eventsApi } from './events';
|
|
export { ticketsApi } from './tickets';
|
|
export { doorApi, DOOR_PAYMENT_METHODS } from './door';
|
|
export type {
|
|
DoorAttendee,
|
|
DoorAttendeesResponse,
|
|
DoorCheckinRequest,
|
|
DoorCheckinResponse,
|
|
DoorEntryMethod,
|
|
DoorMethodTotal,
|
|
DoorPaymentMethod,
|
|
DoorSummary,
|
|
} from './door';
|
|
export { contactsApi } from './contacts';
|
|
export { usersApi } from './users';
|
|
export { paymentsApi } from './payments';
|
|
export { paymentOptionsApi } from './paymentOptions';
|
|
export { mediaApi } from './media';
|
|
export { adminApi } from './admin';
|
|
export { emailsApi } from './emails';
|
|
export { authApi } from './auth';
|
|
export { dashboardApi } from './dashboard';
|
|
export { siteSettingsApi } from './siteSettings';
|
|
export { legalSettingsApi } from './legalSettings';
|
|
export { legalPagesApi } from './legalPages';
|
|
export { faqApi } from './faq';
|
|
export { photosApi } from './photos';
|
|
export type {
|
|
Photo,
|
|
PhotoGallery,
|
|
PhotoGalleryEvent,
|
|
GalleryVisibility,
|
|
CreateGalleryInput,
|
|
} from './photos';
|