Skip to content

Check-in

The Yoyaku Checkin submodule (yoyaku_checkin) admits ticket holders at the door. An operator scans a ticket's QR code and the booking it names is marked attended, through the booking engine's existing complete(), so scanning to mark attendance needs no new booking state.

It builds on Tickets: every ticket already carries a compact QR handle naming its booking or order. Check-in resolves that handle and completes each confirmed booking it names.

Two ways to scan

A ticket's QR encodes a short check-in URL that carries a compact handle in its path (/yykc/<handle>), which powers both flows from one code. The handle is a one-character kind prefix (b for a booking, o for a whole order) and the entity's own opaque key; the path is deliberately short so the QR stays small and scans reliably, and it does not expose the site's administration path.

  • Kiosk scanner page. Open Administration › Booking › Check in (/yykc) on a phone or tablet at the door. The page's camera reads each QR and admits the holder over AJAX without reloading, so a queue moves quickly. It also has a field for typing or wedge-scanning a code when a QR is damaged or the camera is unavailable.
  • Native camera. Point any phone's normal camera (or QR app) at the ticket. It opens the check-in URL in the browser and admits the holder on the spot. The person scanning must be signed in with the check-in permission, so an attendee scanning their own ticket only reaches the sign-in page, never a check-in.

Both need the operator signed in with Check in tickets, and both give the same tri-state feedback below.

Feedback

Every scan produces a big colored banner, a distinct sound, and the order summary so the operator can eyeball who is being admitted:

  • Green, a clean chime — checked in. The banner names the slot.
  • Red, a loud alert — already used. The banner reports who checked the code in and when, so a duplicate ticket is caught.
  • Yellow, a soft tone — refused. The code is invalid or unknown, names a booking that is gone, is not a confirmed booking (for example canceled), or the scan is not on the slot's day.

The slot-day window

Check-in is allowed only on the slot's calendar day(s): the day(s) the booking's slot spans, in the site timezone. A scan on any other day is refused (yellow) and the booking is left untouched, so an early or late arrival cannot be admitted by accident. This slot-day window is the cap on when a handle admits, enforced at scan time rather than baked into the code.

Who checked a code in

Every completion, whether from a door scan or an admin action, is recorded (booking, operator, time). That record is what a repeat scan reads to report "already checked in by … at …".

Access

A dedicated Check in tickets permission gates the page and the URL, separate from administering Yoyaku, so door staff get exactly this and nothing more. Because opening a check-in URL admits on a GET, keep the permission to trusted staff: the handle only identifies the booking, so it is the permission, not the handle, that authorizes a scan, and the URL acts the moment it is opened by someone who holds the permission.

Requirements

Browser camera capture needs a secure context (HTTPS) and, for the in-page kiosk scanner, a browser with the BarcodeDetector API (Chrome / Android). The native-camera flow and the manual field work everywhere.