Provide printable or emailable tickets for confirmed bookings or orders: a PDF carrying a QR code that identifies the booking and can be scanned at the door.

This is a consumer concern that the neutral engine intentionally leaves to a submodule, in the same way it does for payment. The engine already exposes what a ticket needs: a confirmed booking, or a yoyaku_order that groups a submission's bookings (one booker, one payment), each a content entity with a uuid, plus lifecycle events.

Proposed yoyaku_ticket submodule, with no core changes:

  • A verifiable QR token: a signed or HMAC token over the booking or order id/uuid, so a scanner can validate it and it cannot be forged.
  • PDF rendering delegated to existing tooling (Entity Print, a PDF library, or a render service such as Gotenberg), driven by the confirmed booking or order data.
  • A ticket per order (one booker) or per booking/place, configurable.

The scanning side is handled by the attendance check-in submodule, which consumes the QR token produced here. See also the numbered seating submodule.

Issue fork yoyaku-3611638

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mably created an issue. See original summary.

mably opened merge request !71

mably’s picture

mably commented

Attachment delivery landed in Orchestra (#3612558, MR !362): a dispatcher puts NotificationAttachment objects on OrchestraNotificationEvent and both mail channels deliver them. Build each with NotificationAttachment::fromContent(name, mime, bytes) or ::fromUri(name, mime, uri).

File lifecycle is this module's responsibility: Orchestra creates no files and purges none, it only reads what it is given, and it emits no delivered signal to react to.

Recommended for tickets: fromContent. Render the PDF at confirmation time and attach the raw bytes. There is no file, so there is nothing to purge and no timing to get wrong; it is simply regenerated if the confirmation is re-sent.

If a ticket PDF is instead persisted and attached with fromUri, the question of when it may be purged has a sharp answer: the file must survive until the mail is actually transmitted, not merely until the notification is dispatched. With Drupal default synchronous sending the mailer reads and encodes the file during the same request, but a mail spool or queue defers that read to a later run, and Orchestra gives no delivered callback to hook. So do not delete reactively to the send. Own a retention policy instead: track the PDF as a managed file with file usage on the order, or purge on cron keyed to the order reaching a terminal state plus a grace window. That is safe whether sending is synchronous or spooled, and it keeps the file available for a re-send.

Either path keeps the file in private://: the Easy Email channel attaches at the mail layer, not on the Easy Email entity, so a private file is never blocked by Easy Email public-only attachment allowlist.

mably’s picture

mably commented
Status: Active » Needs review

  • mably committed 16f8c743 on 1.x 
    fix: #3611638 Ticket generation submodule (yoyaku_ticket): PDF with QR...
mably’s picture

mably commented
Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.