Painel eletrônico: endpoint /dados não expõe todas as informações da sessão (mesa diretora, presenças, expedientes, matérias, oradores)

[zwinglio]

Comportamento Esperado

As informações da sessão plenária em andamento deveriam estar disponíveis através de uma API (seguindo o padrão REST/DRF já usado em sapl/api/), e não apenas pela view painel/<pk>/dados, que hoje é uma view Django comum protegida por @user_passes_test(check_permission) — ou seja, atrelada à sessão de login do usuário. Como esses dados são públicos por natureza (são exibidos em telão durante a sessão), o consumo não deveria exigir login a cada requisição/poll; a API deveria ser acessível sem essa dependência de sessão autenticada (ex.: AllowAny, como já é feito em sapl/api/deprecated.py e sapl/api/views_health.py).

Além de ser uma API "de verdade", o retorno deveria trazer todas as informações relevantes da sessão plenária em andamento, e não apenas os dados da matéria/votação corrente. Isso permitiria construir uma tela de painel mais completa e também abriria espaço para outros consumidores dessa informação (ex.: apps de acompanhamento externo, integrações).

Especificamente, o retorno deveria incluir:

• Dados da sessão (já existe parcialmente: nome, data, hora de início, status)
• Composição da Mesa Diretora (cargos e parlamentares)
• Presença na sessão (lista de presentes na sessão plenária como um todo)
• Expedientes da sessão (itens do expediente)
• Matérias do expediente (com status/resultado, se houver votação)
• Oradores do expediente
• Matérias da ordem do dia (com status/resultado)
• Presenças na ordem do dia (separado da presença geral da sessão)
• Oradores da ordem do dia
• Status da votação em andamento (já existe parcialmente)

Comportamento Atual

Hoje o get_dados_painel (sapl/painel/views.py:554) retorna um JSON com:

• Metadados da sessão: sessao_plenaria, sessao_plenaria_data, sessao_plenaria_hora_inicio, sessao_solene, sessao_finalizada, tema_solene, status_painel, brasao, mostrar_voto
• Cronômetros: cronometro_aparte, cronometro_discurso, cronometro_ordem, cronometro_consideracoes
• Quando há matéria com votação/registro aberto:
  • presentes (lista de presentes apenas no contexto da matéria em votação, com id, parlamentar_id, nome, partido, voto)
  • num_presentes, oradores (da matéria corrente), msg_painel
  • Dados da matéria em votação: tipo_votacao, materia_legislativa_texto, materia_legislativa_ementa, observacao_materia
  • Placar: numero_votos_sim, numero_votos_nao, numero_abstencoes, total_votos, tipo_resultado, registro

Não retorna: composição da Mesa Diretora, expedientes/matérias do expediente fora do contexto de votação, oradores do expediente separados dos oradores da ordem do dia, presença da sessão como um todo (distinta da presença "no momento da votação"), nem a lista de matérias da ordem do dia fora da matéria corrente em votação.

Não existem hoje serializers/endpoints REST (DRF) para os models IntegranteMesa, SessaoPlenariaPresenca, PresencaOrdemDia, OrdemDia, ExpedienteMateria, OradorExpediente, OradorOrdemDia, RegistroVotacao ou VotoParlamentar — apenas viewsets auto-gerados genéricos via drfautoapi, sem propósito específico para o painel.

Adicionalmente, get_dados_painel está decorado com @user_passes_test(check_permission), então cada chamada depende da sessão de login do usuário no Django (não é uma API com autenticação própria/token, nem é público). Se a sessão expira, a chamada falha/redireciona, e não há como consumir esses dados fora do contexto logado do navegador que abriu o painel.

Possível Solução

• Criar um endpoint de API dedicado (DRF), nos moldes do que já existe em sapl/api/views_sessao.py (que já expõe @action customizadas em SessaoPlenaria, como expedientes e ecidadania), por exemplo: GET /api/sessao/sessaoplenaria/{pk}/painel/.
• Esse endpoint deve agregar os dados de:
  • sessao.models.IntegranteMesa (mesa diretora)
  • sessao.models.SessaoPlenariaPresenca (presença na sessão)
  • sessao.models.PresencaOrdemDia (presença na ordem do dia)
  • sessao.models.ExpedienteMateria e OradorExpediente (expediente)
  • sessao.models.OrdemDia e OradorOrdemDia (ordem do dia)
  • Status de votação (RegistroVotacao/VotoParlamentar), como já é feito hoje em get_dados_painel
• Como o conteúdo é público (exibido em telão), usar permission_classes = (AllowAny,) / authentication_classes = [] (mesmo padrão de sapl/api/deprecated.py e sapl/api/views_health.py), eliminando a dependência de login por poll.
• Criar serializers DRF reutilizáveis em sapl/api/serializers.py para os models acima, já que hoje não existe nenhum.

Contexto

O painel eletrônico é usado ao vivo durante as sessões plenárias e hoje só mostra o que está acontecendo "agora" (matéria em votação). Ter acesso a todos os dados da sessão pela mesma fonte permitiria evoluir o painel (ou construir painéis alternativos) para mostrar o andamento completo da sessão: quem está na mesa, quem discursou, o que já foi lido no expediente, etc., sem depender de múltiplas chamadas a endpoints diferentes ou de dados que hoje simplesmente não são expostos.

Seu Ambiente

• Versão usada 3.1.165-RC2
• Nome e versão do navegador: Irrelevante
• Nome e versão do Sistema Operacional (desktop ou mobile): Irrlevante
• Link para o projeto: Sem fork ainda (volto mais tarde com atualização)

[zwinglio]

TL;DR: O painel eletrônico das sessões plenárias hoje depende da view painel/<pk>/dados, que exige login (@user_passes_test) e retorna só os dados da matéria/votação em andamento... Sem mesa diretora, presença geral da sessão, expediente ou ordem do dia completos.

Isso impede consumo público/externo e limita o painel ao "agora".

Proposta: criar um endpoint DRF público (AllowAny), ex. GET /api/sessao/sessaoplenaria/{pk}/painel/, agregando IntegranteMesa, SessaoPlenariaPresenca, PresencaOrdemDia, ExpedienteMateria/OradorExpediente, OrdemDia/OradorOrdemDia e o status de votação.