lint.yml / feat: per-event organizer name + reply-to on ticket emails (pull_request) Failing after 0s

Details

feat: per-event organizer name + reply-to on ticket emails

Each organizer is different, so the sender identity of ticket emails is
now per event rather than per instance:

- `extra.organizer_name` → From display name "Organizer via <site title>"
  (site title alone when unset). The From address stays the instance
  mailbox — that is what DKIM signs — so this costs nothing in mail auth.
- `extra.reply_to_email` → Reply-To; blank falls back to the email on the
  LNbits account that owns the event wallet; no header when neither
  exists. When a reply-to exists the body says "Questions? Reply to this
  email and it reaches <organizer>", and "Organizer: <name>" is listed
  with the ticket details.

Both fields sit next to the existing per-event subject/body in the admin
dialog. The organizer's own wording (in whatever language) remains
`notification_body`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EYwoAkZZmXMMmaBp4WGUBo

2026-09-13 18:19:33 +02:00

4.3 KiB

Raw Permalink Blame History

Events - LNbits extension

For more about LNBits extension check this tutorial

Sell tickets for events and use the built-in scanner for registering attendees

Events allows you to create tickets for an event. Each ticket is in the form of a unique QR code. After registering and paying, the user gets a QR code to present at registration/entrance.

Events includes a shareable ticket scanner, which can be used to register attendees.

Usage

Create an event
Fill out the event information:
- event name
- wallet (normally there's only one)
- event information
- closing date for event registration
- begin and end date of the event
Share the event registration link
- ticket example
- QR code ticket, presented after invoice paid, to present at registration
Use the built-in ticket scanner to validate registered, and paid, attendees

Guest checkout, card payments and email delivery (aio fork)

Identity. POST /events/api/v1/tickets/{event_id} accepts either an LNbits user_id or a guest name + email; a user_id ticket may also carry an email so logged-in buyers get their ticket mailed.
Payment methods. extra.payment_methods (lightning, fiat) lists the rails an event accepts; an empty list keeps the legacy rule (Lightning always, fiat when allow_fiat). The effective list is published on the NIP-52 event as tickets_payment_methods and enforced at purchase.
Return to the calling app. A client may send frontend_url (its app root, e.g. https://app.example/events). Its origin must be one of LNBITS_CORS_ALLOWED_ORIGINS, the LNbits base URL or LNBITS_CUSTOM_FRONTEND_URL, otherwise the request is refused. Under that root the extension builds the Stripe success_url (/events/{event_id}?checkout=success&tickets=<id,id>), cancel_url (/events/{event_id}?checkout=cancelled) and the emailed ticket link (/events/ticket/{ticket_id}). Absent, the LNbits host is used as before.
Stripe session. The buyer's email is passed as customer_email (prefilled and locked on the hosted page); the line item is named after the event; event_id, quantity and ticket_ids ride along as metadata.
Email. Multipart text + HTML (links, no images) with the ticket card attached — a self-describing PNG (site, event, when, where, QR with the instance logo, name on ticket, ticket id) also served at GET /events/api/v1/ticket-card/{ticket_id}; the bare QR stays at GET /events/api/v1/qr/{ticket_id}. Headers carry Date, Message-ID and a From display name — extra.organizer_name gives "Organizer via ", otherwise the site title. Replies go to extra.reply_to_email, falling back to the event owner's account email (no Reply-To when neither exists). The From address is always the instance mailbox, which is what DKIM signs. POST /events/api/v1/tickets/{ticket_id}/resend-email returns a TicketResendResult with per-channel outcome.

Powered by LNbits

LNbits is a free and open-source lightning accounts system.