Control de acceso en la puerta

Cómo registra el personal la entrada de las personas en la puerta: elegir una sesión, escanear un código QR con la cámara o escribir un código, qué significa cada resultado, las alertas de la puerta y quién puede escanear qué sesión.

Para el paquete Full Stack

La página de la puerta

El control de acceso se abre en /en/dashboard/check-in. El personal elige el evento y su sesión, y la página muestra si las puertas están abiertas, cuántas personas han entrado de cuántas se esperan, los últimos escaneos y las alertas pendientes. Las puertas cuentan como abiertas desde dos horas antes del inicio, o desde que entra alguien, hasta el final. La página lista las sesiones de los eventos publicados y agotados que terminaron hace menos de 24 horas.

El control de acceso necesita conexión: no hay una cola sin conexión que reproducir más tarde, y la página se pausa mientras no hay conexión.

Escanear una entrada

Enable camera y apúntala al código QR de la entrada, o escribe el código en Enter code manually: una referencia de entrada como TKT-1042-1 sirve igual que el texto del código QR. La cámara permanece apagada hasta que se enciende, y sus imágenes nunca salen del dispositivo.
Primero se comprueba la entrada sin dejar entrar a nadie, y el resultado muestra el titular, el asiento y el tipo de entrada.
Confirm check-in la admite. Next ticket borra el resultado para la siguiente persona.

La cámara se lee en el navegador con su lector de códigos integrado, o con jsQR cuando el navegador no tiene ninguno. Un navegador que no puede usar una cámara aquí sigue comprobando los códigos escritos.

Qué significa cada resultado

Resultado	Significado
Ticket valid	Puede ser admitida. No ocurre nada hasta Confirm check-in.
Check-in realizado	Admitida ahora.
Already admitted	Ya entró antes; el resultado dice cuándo y quién.
Wrong event	La entrada es de otro evento o sesión.
Ticket void	Reembolsada, a la espera de un reembolso, anulada, sin pagar, o su evento se canceló.
Ticket not found	Ninguna entrada coincide con el código. El código QR antiguo de una entrada reemitida se lee así.

Una entrada se admite una vez por sesión, pase lo que pase: dos puertas que la escanean en el mismo instante la dejan entrar una sola vez, y la segunda ve quién lo hizo.
Se puede reintentar con seguridad tras una conexión caída: se envía de nuevo el mismo intento, así que nadie es admitido dos veces.
Un reembolso o una reemisión hechos un segundo antes del escaneo ganan.

Alertas de la puerta

Un escaneo que acaba como ya admitida, evento equivocado o anulada cuenta como algo que necesita atención hasta que alguien pulsa Acknowledge en la página de la puerta. El resumen las suma a su propio recuento, y mientras el interruptor de alertas de control de acceso del espacio de trabajo esté activado, cada una hace sonar la campana de todos los miembros que pueden publicar eventos. Cada escaneo queda registrado, sin el código en sí.

Unos datos de ejemplo recién creados tienen 1.127 admisiones y 8 alertas pendientes: City Fest tiene 27 de sus 50 entradas dentro y 3 alertas, y cada otro organizador tiene una puerta abierta ahora.

Quién puede escanear qué sesión

Cada paso del control de acceso necesita checkin.scan. Los roles de ejemplo Propietario, Gerente y Control de acceso lo tienen.
Un miembro que puede editar o publicar eventos (los roles de ejemplo Propietario y Gerente) puede escanear todas las sesiones. Cualquier otro, como el rol de Control de acceso, escanea solo las sesiones que tiene asignadas, y se le avisa cuando no tiene ninguna.
Las sesiones se asignan en la página del miembro en Team, en Check-in sessions, por un miembro que pueda editar el equipo (admins.edit).
La cuenta de control de acceso de ejemplo escanea City Fest y Design Talks en Northline Events, y Winter Science Weekend y Winter Lights Trail en Meadow Days; sus datos de acceso están en la guía de instalación.

Límites

Cada miembro del personal puede hacer 120 peticiones de control de acceso por minuto desde una misma dirección, así que un lector no sirve para probar códigos. Detrás de un proxy inverso, define TRUST_PROXY=1 en el .env de la API para que la dirección sea la propia del lector.

Las rutas que hay detrás

POST /api/admin/check-in/validate examina una entrada y no admite nada; POST /api/admin/check-in/admit acepta además un client_request_id (un UUID por intento) y responde con la admisión original cuando se envía de nuevo. Ambos aceptan { session_code, code }; el código de una sesión es el slug del evento seguido de -main (design-talks-main).
Rechazos: 404 NOT_FOUND, 409 WRONG_SESSION, 409 TICKET_VOID, 409 ALREADY_ADMITTED, 403 session_not_assigned y 429 al superar el límite de peticiones.
GET /api/admin/check-in/sessions/:code/summary y /scans leen las cifras de la puerta y sus 20 últimos escaneos; POST .../acknowledge borra sus alertas. PUT /api/admin/session-staff/:code define quién escanea una sesión.

Referencia de la API