generated from bisco/codex-bootstrap
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# ADR-0006: Staff Check-In with Token Validation
|
|
|
|
Date: 2026-04-28
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
Confirmed reservations need a simple entrance check-in process. Staff should be able to use a mobile-friendly web page to scan a visitor's QR code or enter the token manually.
|
|
|
|
QR codes may be shown on smartphones, printed, forwarded, or photographed, so they must not expose personal data. Check-in must be restricted to authenticated staff or admin users and must prevent duplicate entrance.
|
|
|
|
## Decision
|
|
|
|
Use staff-only Django REST Framework endpoints for QR verification preview and check-in confirmation.
|
|
|
|
The QR code will contain only an opaque verification token or URL. The backend will validate the token server-side, require a confirmed reservation, reject duplicate check-ins, and create or update a `CheckIn` record with timestamp and staff user on successful confirmation.
|
|
|
|
No Celery, Redis, or separate check-in service is required.
|
|
|
|
## Consequences
|
|
|
|
- Staff can use a simple mobile web page for scanning or manual token entry.
|
|
- QR codes remain privacy-preserving because they do not contain personal data.
|
|
- Check-in decisions stay centralized in the Django backend and PostgreSQL state.
|
|
- The entrance workflow depends on backend availability at the venue.
|
|
- Duplicate check-ins can be blocked with application checks and database constraints.
|