Contrôle des billets à l'entrée

Comment l'équipe contrôle les billets à l'entrée : choisir une session, scanner un code QR avec la caméra ou saisir un code, ce que signifie chaque résultat, les alertes d'entrée, et qui peut scanner quelle session.

Pour le pack Full Stack

La page d'entrée

Le contrôle des billets s'ouvre sur /en/dashboard/check-in. L'équipe choisit l'événement et sa session, et la page indique si les portes sont ouvertes, combien de personnes sont contrôlées sur combien attendues, les derniers scans et les alertes en attente. Les portes comptent comme ouvertes deux heures avant le début, ou dès que quelqu'un est entré, jusqu'à la fin. La page liste les sessions des événements publiés et complets terminés depuis moins de 24 heures.

Le contrôle des billets exige une connexion : il n'y a pas de file hors ligne à rejouer plus tard, et la page se met en pause tant que la connexion est coupée.

Scanner un billet

Enable camera et pointez-la vers le code QR du billet, ou saisissez le code dans Enter code manually : une référence de billet comme TKT-1042-1 fonctionne aussi bien que le texte du code QR. La caméra reste éteinte tant qu'on ne l'allume pas, et ses images ne quittent jamais l'appareil.
Le billet est d'abord vérifié sans faire entrer personne, et le résultat affiche le titulaire, la place et le type de billet.
Confirm check-in le fait entrer. Next ticket efface le résultat pour la personne suivante.

La caméra est lue dans le navigateur avec son lecteur de codes-barres intégré, ou avec jsQR quand le navigateur n'en a pas. Un navigateur qui ne peut pas utiliser de caméra ici vérifie quand même les codes saisis.

Ce que signifie chaque résultat

Résultat	Signification
Billet valide	Il peut être admis. Rien ne se passe avant Confirm check-in.
Arrivée enregistrée	Admis à l'instant.
Déjà admis	Il est déjà entré ; le résultat indique quand et par qui.
Mauvais événement	Le billet est pour un autre événement ou une autre session.
Billet annulé	Remboursé, en attente de remboursement, annulé, impayé, ou son événement a été annulé.
Billet introuvable	Aucun billet ne correspond au code. L'ancien code QR d'un billet réémis donne ce résultat.

Un billet est admis une fois par session, quoi qu'il arrive : deux portes qui le scannent au même moment le font entrer une seule fois, et la seconde voit qui l'a fait.
Une connexion coupée peut être retentée sans risque : la même tentative est renvoyée, personne n'est donc admis deux fois.
Un remboursement ou une réémission faits une seconde avant le scan l'emportent.

Alertes d'entrée

Un scan qui se termine par déjà admis, mauvais événement ou annulé compte comme demandant de l'attention jusqu'à ce que quelqu'un appuie sur Acknowledge sur la page d'entrée. La vue d'ensemble les ajoute à son propre compteur, et tant que le réglage des alertes de contrôle de l'espace de travail est activé, chacune fait sonner la cloche de chaque membre qui peut publier des événements. Chaque scan est consigné, sans le code lui-même.

Des données d'exemple neuves ont 1 127 admissions et 8 alertes en attente : City Fest a 27 de ses 50 billets entrés et 3 alertes, et chacun des autres organisateurs a une entrée ouverte en ce moment.

Qui peut scanner quelle session

Chaque étape du contrôle exige checkin.scan. Les rôles Propriétaire, Gestionnaire et Contrôle des billets des données d'exemple la détiennent.
Un membre qui peut modifier ou publier des événements (le Propriétaire et le Gestionnaire d'exemple) peut scanner toutes les sessions. Tout autre, comme le rôle Contrôle des billets, ne scanne que les sessions qui lui sont attribuées, et on le lui dit quand il n'y en a aucune.
Les sessions sont attribuées sur la page du membre sous Équipe, dans Check-in sessions, par un membre qui peut modifier l'équipe (admins.edit).
Le compte de contrôle d'exemple scanne City Fest et Design Talks chez Northline Events, et Winter Science Weekend et Winter Lights Trail chez Meadow Days ; ses identifiants de connexion sont dans le guide d'installation.

Limites

Chaque membre de l'équipe peut faire 120 requêtes de contrôle par minute depuis une même adresse : un scanner n'est donc pas un moyen d'essayer des codes. Derrière un reverse proxy, définissez TRUST_PROXY=1 dans le .env de l'API pour que l'adresse soit celle du scanner lui-même.

Les routes derrière

POST /api/admin/check-in/validate examine un billet et n'admet personne ; POST /api/admin/check-in/admit prend aussi un client_request_id (un UUID par tentative) et répond avec l'admission d'origine quand il est renvoyé. Les deux prennent { session_code, code } ; le code d'une session est le slug de l'événement suivi de -main (design-talks-main).
Refus : 404 NOT_FOUND, 409 WRONG_SESSION, 409 TICKET_VOID, 409 ALREADY_ADMITTED, 403 session_not_assigned, et 429 au-delà de la limite de débit.
GET /api/admin/check-in/sessions/:code/summary et /scans lisent les chiffres de l'entrée et ses 20 derniers scans ; POST .../acknowledge efface ses alertes. PUT /api/admin/session-staff/:code définit qui scanne une session.

Référence de l'API