Skip to content

Painel Público de Status (kiosk) ​

O que é este documento — o mapa da quarta superfície do ionCLASS: o painel público de status, um kiosk exibido na portaria/recepção que mostra a fila de retirada ao vivo sem dados sensíveis. É autenticado por token de kiosk (não por sessão de usuário) e vive dentro do próprio backend (página Inertia). Superfícies irmãs: App do Responsável, Monitor de Portaria e Painel Administrativo.


1. Propósito ​

Uma tela pública (Chrome em fullscreen) na portaria/recepção que mostra, ao vivo, quais crianças já foram sinalizadas para retirada e em que status — para que responsáveis e crianças acompanhem a fila num telão, sem operador. Diferente do monitor de portaria, aqui ninguém opera: é somente leitura, e por ser uma tela pública não pode exibir dado sensível.

A página é forçada em dark para contraste/legibilidade a distância (pátio), exibe um relógio de parede e um card por criança na fila. Estado vazio: "Aguardando chegadas — Use o botão 'Estou Chegando' no aplicativo".

2. Autenticação por token de kiosk ​

Não há login de usuário. O acesso é por um token de kiosk, gerado no painel administrativo: um token opaco (64 caracteres hexadecimais aleatórios) que pertence a uma escola.

  • Cada token pertence a uma escola, tem um rótulo, uma segmentação opcional (portões e turmas, ver §2.2) e uma validade opcional, registra quem o criou e quando foi usado pela última vez, e pode ser revogado. Um token é ativo quando não está revogado E não está expirado.
  • Um middleware de validação de token protege tanto a página quanto os endpoints de suporte. O token chega via querystring ?token=… (o kiosk é aberto com a URL contendo o token) ou pelo header X-Monitor-Token.
  • O kiosk faz um heartbeat a cada 5 min (GET /api/v1/public-monitor/{school}/heartbeat): 200 = ainda válido; 401 = token rotacionado/revogado/expirado → a tela mostra o overlay "Exibição expirada. Recarregue a página." (não reconecta sozinho, para não vazar estado com token morto). O heartbeat também registra o último uso do token.

2.1 Provisionamento (no painel admin) ​

Os tokens são gerenciados na aba "Configurações" do detalhe da escola (superfície Painel Administrativo), restritos à permissão de configurações da escola e ao escopo da própria escola. Ações:

AçãoRota
GerarPOST /admin/schools/{school}/public-monitor-tokens
Editar (rótulo + segmentação)PATCH /admin/schools/{school}/public-monitor-tokens/{token}
RotacionarPOST /admin/schools/{school}/public-monitor-tokens/{token}/rotate
RevogarDELETE /admin/schools/{school}/public-monitor-tokens/{token}

O admin copia a URL com o ?token= e a abre no dispositivo do kiosk em fullscreen. Ao rotacionar, o novo token herda o rótulo, a validade e a segmentação do anterior.

2.2 Segmentação por portões e turmas ​

Assim como o operador escolhe na configuração de trabalho do tablet quais portões e turmas acompanha, cada painel público pode ser restrito a alguns portões e/ou turmas. Isso permite, por exemplo, uma TV no portão A que só mostra quem vai sair pelo portão A. A segmentação é um atributo do token, então cada TV tem a sua URL e o seu recorte, e se escolhe no mesmo diálogo de gerar/editar da aba "Configurações":

  • Portões: o aluno aparece se o portão do sinal de chegada dele está entre os escolhidos.
  • Turmas: o aluno aparece se qualquer uma das turmas dele está entre as escolhidas (um aluno em duas turmas escolhidas aparece uma vez só). Os turnos aparecem no diálogo só como atalho para filtrar a lista de turmas; eles não são gravados.
  • Nada selecionado = tudo. Uma lista vazia não filtra: sem portões escolhidos, o painel mostra todos os portões, e o mesmo vale para as turmas. Os tokens anteriores à segmentação continuam mostrando a escola inteira.
  • Portão e turma juntos: o aluno precisa satisfazer os dois recortes.
  • Irmãos entram juntos: se algum aluno de um sinal está no recorte, os irmãos do mesmo sinal que ainda estão na fila também aparecem, igual ao board do operador. O responsável leva todos de uma vez, pelo mesmo portão.

Um painel segmentado mostra o rótulo do token abaixo do nome da escola, para identificar qual TV é qual. A mudança de segmentação vale a partir da próxima atualização da tela, que acontece a cada evento do canal, sem trocar a URL.

3. Payload privacy-safe (6 campos) ​

O cartão público é a fonte única do formato exibido e impõe o requisito de privacidade: somente estes seis campos cruzam o canal público — nunca nome completo, foto, id interno, responsável ou coordenadas.

CampoConteúdo
card_idUUID opaco derivado do sinal de chegada + criança (UUIDv5), nunca o id do aluno. É estável entre eventos, então updates e fades miram o mesmo card, e irmãos do mesmo sinal têm cards distintos
student_first_nameSó o primeiro nome da criança
class_nameSó a 1ª turma (expor a lista completa vazaria a rotina/extracurriculares da criança)
statusO estado de retirada (mapeado para rótulo público na tela)
sinceISO-8601 de quando entrou nesse estado (exibido como tempo relativo)
late_sinceISO-8601 de quando o responsável passou a contar como atrasado (o operador estendeu a liberação na portaria), ou null. É marcador de status, não dado pessoal: o card mostra o selo Em atraso · há N min ao lado de "Pronto para sair" — o aluno segue liberado. Apaga quando a liberação é revogada; some junto com o card na retirada

4. Tempo real (canal público) ​

A página assina o canal school.{id}.public-monitor — um canal público (Reverb), porque os eventos que trafegam nele já são o cartão privacy-safe de 6 campos. As credenciais vêm de GET /api/v1/public-monitor/{school}/credentials ({ key, channel }). Três eventos:

Evento (wire)Payload
ArrivalSignalCreated{ cards: [card…] } — um card por irmão do sinal
StudentStateChangedum card (6 campos) — inclusive quando só o late_since mudou (marcar/limpar o atraso), sem troca de estado
PickupConfirmedapenas { card_id } — a criança sai da tela (fade); nenhuma identidade cruza o canal

O canal é um só por escola, mesmo com painéis segmentados. Cada evento faz a página recarregar os cards pela mesma consulta do servidor, e é essa consulta que aplica a segmentação do token. Por isso o evento de um portão que a TV não mostra não faz aparecer nada nela.

A autorização do canal é defesa em profundidade: só autoriza quando o contexto de escola resolvido pelo token bate com a escola pedida. O verdadeiro portão é a validação do token de kiosk na página e nos endpoints.

5. Onde o código vive ​

Diferente das superfícies mobile/monitor (repos próprios), o painel público é servido pelo próprio backend: uma página Inertia que renderiza os sinais ativos não terminados (filtrados pela segmentação do token), mais os endpoints de suporte de heartbeat e credenciais.

6. Ver também ​

Documentação do ionCLASS