Organizer ticket management view (resend email, registration status, refunds) #60

Open
opened 2026-05-22 10:32:54 +00:00 by padreug · 0 comments
Owner

Context

Events extension v1.6.1 added a POST /tickets/{ticket_id}/resend-email endpoint (upstream PR #51) — admin-key-only, lets the organizer re-deliver a ticket confirmation email after the initial send (e.g. buyer's inbox filtered the first one).

The API client method exists already (TicketApiService.resendTicketEmail, added in 94c54a5 during the v1.6.1 alignment pass), but there's no UI surface in the webapp for organizers to call it. MyTicketsPage is buyer-side; ActivityDetailPage shows the activity but not the ticket list; there's no per-event ticket admin view at all.

Scope

Build an organizer-only ticket list visible on the event they own. Pulls from GET /events/api/v1/tickets?all_wallets=true filtered to the current event. Per row:

  • Buyer name / email (or anon "user_id only" indicator for Nostr-id tickets)
  • Paid / unpaid badge
  • Registered (at-the-door scan) badge
  • Resend email button — visible only when ticket is paid AND has email
  • Optional: refund button (paid + non-registered events with a refund window?)
  • Optional: ticket creation time, total paid (extra.sats_paid)

Where to put it:

  • Easiest: collapsible "Manage tickets ({n})" panel on ActivityDetailPage shown when ownedLnbitsEvent is set (i.e. current user is organizer).
  • Alternative: separate route /activities/:id/tickets with the full list. Better for scaling but more nav surface.

I'd lean panel on the detail page first; can promote to a separate route later if the list grows.

Out of scope

  • Cross-event ticket dashboard (organizer sees all their tickets across events). Different problem, needs aggregation across events. Build only if there's demand.
  • CSV export. LNbits admin UI already does this; webapp can defer.
  • API client method already in place: src/modules/activities/services/TicketApiService.ts:resendTicketEmail
  • Notification metadata surfaced on the type: ActivityTicketExtra.email_notification_sent (so the UI could show "delivered" vs "not yet sent" state).
## Context Events extension v1.6.1 added a `POST /tickets/{ticket_id}/resend-email` endpoint (upstream PR #51) — admin-key-only, lets the organizer re-deliver a ticket confirmation email after the initial send (e.g. buyer's inbox filtered the first one). The API client method exists already (`TicketApiService.resendTicketEmail`, added in `94c54a5` during the v1.6.1 alignment pass), but **there's no UI surface** in the webapp for organizers to call it. `MyTicketsPage` is buyer-side; `ActivityDetailPage` shows the activity but not the ticket list; there's no per-event ticket admin view at all. ## Scope Build an organizer-only ticket list visible on the event they own. Pulls from `GET /events/api/v1/tickets?all_wallets=true` filtered to the current event. Per row: - Buyer name / email (or anon "user_id only" indicator for Nostr-id tickets) - Paid / unpaid badge - Registered (at-the-door scan) badge - **Resend email** button — visible only when ticket is paid AND has email - Optional: refund button (paid + non-registered events with a refund window?) - Optional: ticket creation time, total paid (extra.sats_paid) Where to put it: - Easiest: collapsible "Manage tickets ({n})" panel on `ActivityDetailPage` shown when `ownedLnbitsEvent` is set (i.e. current user is organizer). - Alternative: separate route `/activities/:id/tickets` with the full list. Better for scaling but more nav surface. I'd lean panel on the detail page first; can promote to a separate route later if the list grows. ## Out of scope - Cross-event ticket dashboard (organizer sees all their tickets across events). Different problem, needs aggregation across events. Build only if there's demand. - CSV export. LNbits admin UI already does this; webapp can defer. ## Related - API client method already in place: `src/modules/activities/services/TicketApiService.ts:resendTicketEmail` - Notification metadata surfaced on the type: `ActivityTicketExtra.email_notification_sent` (so the UI could show "delivered" vs "not yet sent" state).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/webapp#60
No description provided.