RF-008 – TCE-Push – Serviço de Acompanhamento de Processos por E-mail

Funcionalidade que permite a qualquer cidadão ou entidade receber notificações por e-mail sobre movimentações em processos autuados no Tribunal de Contas do Estado de Goiás, sem necessidade de cadastro com senha. O acesso ao serviço ocorre diretamente na página do processo, via widget inline, e o gerenciamento das inscrições é realizado por links presentes nos próprios e-mails recebidos.

Local de acesso:

• Widget de inscrição: /processo/{id} (bloco abaixo do cabeçalho do processo)
• Página de confirmação: /acompanhar-processo/confirmar?token={token}
• Página de gerenciamento: /acompanhar-processo/gerenciar?token={token}
• Página de cancelamento: /acompanhar-processo/cancelar?token={token}&processo={id}

Bloco exibido inline na página do processo, logo abaixo do cabeçalho, permitindo ao usuário se inscrever para receber notificações por e-mail. O widget transita entre estados sem recarregar a página.

— Estado idle

— Estados formulario e loading

— Estado confirmacao-pendente

— Estado inscrito

Tela acessada pelo link presente no e-mail de confirmação. Valida o token recebido e exibe o resultado da operação. Não possui campos editáveis além do redirecionamento.

— Confirmação bem sucedida

— Link expirado

Tela acessada pelo link presente nos e-mails de notificação. Exibe a lista de processos acompanhados pelo e-mail associado ao token e permite o cancelamento individual de acompanhamentos. Em caso de token expirado, exibe formulário para reenvio do link.

Tela acessada pelo link “Parar de receber este acompanhamento” presente nos e-mails de notificação. Executa o cancelamento imediato do processo referenciado no token e exibe o resultado da operação. Não possui campos editáveis.

— Cancelamnto bem sucedido

— Link expirado ou já utilizado

Todos os e-mails seguem o padrão visual institucional do TCE-GO, são remetidos pelo endereço `push@tce.go.gov.br` e despachados pelo servidor `smtp.tce.go.gov.br`, reaproveitando a camada de serviço compartilhada `IServicoDeEmail`/`ServicoDeEmail` (`TCE.Compartilhado.Servico.Servicos.Contato`), a mesma já utilizada por `ServicoDeUsuarioPush` no legado. O RF-008 não deve implementar um novo mecanismo de envio — apenas montar `DtoEmail` (remetente, destinatário, assunto, corpo HTML) e chamar essa camada compartilhada, como já ocorre em `ServicoDeUsuarioPush.EnviaEmail`. Nenhuma ação dos e-mails depende de login — cada link carrega o token correspondente (RN02, RN09) e o ID de autuação do processo, quando aplicável.

Disparado ao final do Fluxo 01 (passo 07.1), sempre que uma inscrição em um processo aguarda confirmação — inclusive para e-mails que já confirmaram outros processos anteriormente (RN03).

Disparado sempre que houver uma movimentação em um processo já confirmado. O disparo e a montagem da mensagem ocorrem na rotina PL/SQL de notificação, dentro do banco (ver Mecanismo de Disparo da Notificação). O RF-008 especifica o conteúdo, o layout e os links; a implementação do template é feita onde o disparo acontece.

Disparado ao final do Fluxo 05, somente quando o e-mail informado possui acompanhamentos ativos na base — o backend nunca confirma nem nega essa condição na resposta exibida ao usuário (RN08). O envio (ou não) deste e-mail é a única diferença observável entre “e-mail existe” e “e-mail não existe”.

<WRAP center round info> Nota de segurança (RN16). O token de descadastro autoriza apenas a remoção do acompanhamento referenciado. Concluído o cancelamento, a tela não exibe a lista de processos acompanhados nem oferece acesso direto ao painel — quem quiser ver a lista completa precisa passar pelo Fluxo 05, informando o e-mail e recebendo um token de sessão. </WRAP>

Esta seção documenta, para o time de backend, quais estruturas do sistema legado (banco de dados, rotinas armazenadas e API) devem ser reaproveitadas na implementação do RF-008 modernizado, e quais precisam ser substituídas ou criadas. A diretriz central é: o novo modelo não expõe cadastro de usuário ao público, mas continua persistindo um registro de usuário “por baixo dos panos”, reutilizando a tabela e as rotinas já existentes, de modo a não quebrar os vínculos de quem já se cadastrou pelo fluxo antigo (Portal legado `/Push`).

Padrão adotado no RF-008: toda a comunicação entre telas, e-mails e API é feita pelo ID interno da autuação (`PROAUTU_ID`). O número público do processo (`CODG_PROCESSO_N`) é usado apenas para exibição ao usuário — nunca como identificador em requisições, tokens ou parâmetros de rota.

O e-mail de movimentação do Push legado não é disparado pela aplicação. Ele nasce inteiramente dentro do banco Oracle, em duas etapas:

1. Enfileiramento (imediato). Todo registro de andamento gravado em `PRO_ANDAMENTO` marca, via trigger, as inscrições daquele processo como “pendentes de notificação”.
2. Envio (a cada 3 minutos). Uma rotina agendada varre as inscrições pendentes, monta o e-mail e o despacha por `smtp.tce.go.gov.br`, com remetente `push@tce.go.gov.br`.

O mecanismo foi verificado de ponta a ponta em 06/09/2026 e está operacional. O detalhamento técnico — objetos de banco, defeitos catalogados (D1–D10) e procedimento de teste — está no PRD, seção 12.

O template do E-mail 02 é implementado na própria rotina de disparo, em PL/SQL. O RF-008 especifica conteúdo, layout e links; a construção da mensagem permanece onde o envio acontece. Decorre daí:

• Os campos acrescentados ao E-mail 02 — Órgão ou Setor Atual, Data Autuação e Ano Referência — já estão disponíveis nas views consultadas pela rotina. Não é necessária nova fonte de dados.
• O token de descadastro (RN16) precisa estar acessível à rotina no momento da montagem do link. A rotina apenas lê o token; a geração ocorre na inscrição, no serviço do RF-008.
• Os links passam a usar HTTPS e deixam de transportar o e-mail do destinatário em query string, corrigindo a falha de segurança do modelo legado.

• Enfileiramento sem filtro. Toda gravação de andamento entra na fila, sem distinção de situação, setor, tipo de documento ou sigilo — inclusive os andamentos gerados em cascata para processos apensados.
• Filtragem apenas no envio. A notificação deixa de ser enviada quando o usuário está desabilitado, quando a inscrição não tem usuário correspondente, ou quando a autuação está marcada com bloqueio total de documento.
• Eventos de pauta e julgamento também alimentam a fila, por caminho próprio e independente do fluxo de tramitação.

Processos sigilosos não geram notificação de movimentação. A definição de sigilo para este serviço é a regra já aplicada na view de acompanhamento: a notificação é suprimida quando a autuação está marcada com bloqueio total de documento.

Os demais processos são notificados normalmente — inclusive os marcados como reservados e os de bloqueio parcial. O fundamento é que os dados levados pelo e-mail (setor atual, situação, assunto, datas de autuação e referência) já estão disponíveis publicamente na consulta de processos do Portal: a notificação não amplia a exposição existente, apenas avisa o interessado de que ela mudou.

O comportamento atual não será alterado pelo RF-008. Decisão de Requisitos, 06/09/2026.

Comportamentos do legado que não estão documentados como decisão e precisam ser confirmados por Requisitos antes da implementação do RF-008:

• Não sobrescrever cadastros existentes: e-mails que já possuem registro em `PSH_USUARIOS` (vindos do Push legado, com `Nome`/`Senha`/`Habilitado` reais) devem ser localizados por `DESC_EMAIL_A` e reaproveitados como estão — o upsert do cadastro implícito (RN12) só deve inserir quando não houver registro; nunca deve atualizar `Nome`, `Senha` ou rebaixar `Habilitado` de um cadastro pré-existente.
• Descolar “Habilitado” de “ativação de conta”: o significado de `HABILITADO_N` muda de “conta ativada” (legado) para “e-mail confirmado em ao menos um processo” (RF-008); é preciso garantir que usuários migrados do legado com `Habilitado = 0` (nunca ativaram a conta) não fiquem bloqueados ao usar o novo fluxo de confirmação por processo.
• ID de Autuação como identificador único do processo: todo o contrato do RF-008 (requisições da API, tokens de confirmação/gerenciamento/cancelamento, parâmetros de rota) deve referenciar o processo pelo ID de autuação. O número público do processo é apenas informação de exibição nas telas e nos e-mails. A única exceção no legado é `WEB_PACKAGE.PWEB_ACOMPANHAPROCESSO`, que exige o número público — tratar como conversão isolada no ponto de integração, sem propagar o número para o restante do fluxo (ver tabela de rotinas acima).
• Nenhuma estrutura de token existente é reaproveitável tal como está: o legado não possui tabela/mecanismo de token com expiração para os links de confirmação/gerenciamento/cancelamento; isso é desenvolvimento novo, não reaproveitamento.

— Gerado com: documentar-funcionalidade-v1.md
Revisado por: Paulo Ricardo Amorim Silva - pramorim@tce.go.gov.br