pres:gerti:gestao_de_ativos:portal:er_008

Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

Link para esta página de comparações

Ambos lados da revisão anterior Revisão anterior
Próxima revisão		 Revisão anterior
pres:gerti:gestao_de_ativos:portal:er_008 [31/08/2026 20:24] – pramorimpres:gerti:gestao_de_ativos:portal:er_008 [08/09/2026 16:49] (atual) – pramorim
Linha 7: Linha 7:
   * Página de confirmação: ''/acompanhar-processo/confirmar?token={token}''   * Página de confirmação: ''/acompanhar-processo/confirmar?token={token}''
   * Página de gerenciamento: ''/acompanhar-processo/gerenciar?token={token}''   * Página de gerenciamento: ''/acompanhar-processo/gerenciar?token={token}''
-  * Página de cancelamento: ''/acompanhar-processo/cancelar?token={token}&processo={id}''+  * Página de cancelamento: ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''
  
 ---- ----
Linha 135: Linha 135:
  
 ==== E-mail 02 – Notificação de Movimentação ==== ==== E-mail 02 – Notificação de Movimentação ====
-{{:pres:gerti:gestao_de_ativos:portal:movimentacao_-_tce_go_push-_localhost_.png?direct&600|}} \\+{{:pres:gerti:gestao_de_ativos:portal:pasted:20260907-131356.png?direct&600}} \\
  
-Disparado sempre que houver uma movimentação em um processo já confirmado. **O disparo é executado por outro serviço interno do TCE-GO**, externo ao escopo do RF-008 e ao protótipo: o RF-008 define o conteúdo e os links da mensagem, não a regra que decide quando enviá-la.+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_notificacao_legado|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.
  
 ^Elemento^Conteúdo^Observação| ^Elemento^Conteúdo^Observação|
 |Remetente|`push@tce.go.gov.br`|Endereço institucional único para os três e-mails do RF-008.| |Remetente|`push@tce.go.gov.br`|Endereço institucional único para os três e-mails do RF-008.|
 |Assunto|"Serviço de acompanhamento de processos TCE-GO — Movimentação no processo Nº {numero}"| | |Assunto|"Serviço de acompanhamento de processos TCE-GO — Movimentação no processo Nº {numero}"| |
-|Corpo|Número do processo, descrição da movimentação e data|Dados somente para leitura; não há ação além dos links abaixo.|+|Corpo — identificação|Número do processo| | 
 +|Corpo — **Andamento atual**|"Órgão ou Setor Atual: {setor}" (ex.: "DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO - DI-TI") e data da movimentação|Informa **para onde** o processo foi movimentado — é o dado que motiva a notificação.| 
 +|Corpo — **Dados da autuação**|"Data Autuação: {data}" e "Ano Referência: {ano}"|Contextualizam o processo para quem acompanha vários.|
 |Link "Ver processo completo"|Redireciona para ''/processo/{id}''|Consulta pública do processo, sem necessidade de token.| |Link "Ver processo completo"|Redireciona para ''/processo/{id}''|Consulta pública do processo, sem necessidade de token.|
-|Link "Gerenciar meus acompanhamentos"|Redireciona para ''/acompanhar-processo/gerenciar?token={token}''|Aciona o **Fluxo 03**. Token único do serviço, uso múltiplo dentro das 48h de validade (RN02, RN09).| +|Link "Solicitar link de gerenciamento"|Redireciona para ''/acompanhar-processo/gerenciar'' — **sem token**|A rota sem token apresenta o formulário de solicitação, acionando o **Fluxo 05**. Este e-mail **não carrega token de sessão**: chega semanas ou meses após a inscrição, quando qualquer token de 48h já expirou (RN02).| 
-|Link "Parar de acompanhar este processo"|Redireciona para ''/acompanhar-processo/cancelar?token={token}&processo={id}''|Aciona o **Fluxo 04**. Remove apenas o processo referenciado neste link — não afeta os demais acompanhamentos do e-mail (RN07).|+|Link "Parar de acompanhar este processo"|Redireciona para ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''|Aciona o **Fluxo 04**, com o **hash de descadastro** (RN16) — persistente e de escopo único — e o ID do acompanhamento. Remove apenas o vínculo referenciado, e **não dá acesso ao painel** (RN07, RN17).|
  
 ==== E-mail 03 – Reenvio de Link de Gerenciamento ==== ==== E-mail 03 – Reenvio de Link de Gerenciamento ====
Linha 198: Linha 200:
  
 ^Passo^Ação^Regra^Tela| ^Passo^Ação^Regra^Tela|
-|01|Usuário recebe o e-mail de notificação de movimentação com link "Gerenciar meus acompanhamentos"| |E-mail 02|+|01|Usuário acessa o painel por uma de duas origens: o link "Gerenciar meus acompanhamentos" do **E-mail 03** (com token de sessão), ou o link "Solicitar link de gerenciamento" do **E-mail 02**, que leva ao formulário do Fluxo 05 e resulta no envio do E-mail 03|RN02 RN16|E-mail 02 · E-mail 03|
 |02|Usuário clica no link| | | |02|Usuário clica no link| | |
-|03|O sistema redireciona para ''/acompanhar-processo/gerenciar?token={token}''| |Tela 03| +|03|O sistema redireciona para ''/acompanhar-processo/gerenciar?token={token}''; sem token, a rota apresenta o formulário de solicitação (Fluxo 05)|RN02|Tela 03| 
-|04|O sistema exibe o estado loading: "Carregando seus acompanhamentos…" e valida o token|RN09|Tela 03|+|04|O sistema exibe o estado loading: "Carregando seus acompanhamentos…" e valida o token de sessão|RN09|Tela 03|
 |05|Token válido|RN09| | |05|Token válido|RN09| |
 |05.1|O sistema exibe a primeira página da lista de processos acompanhados pelo e-mail associado ao token, com o e-mail mascarado|RN09|Tela 03| |05.1|O sistema exibe a primeira página da lista de processos acompanhados pelo e-mail associado ao token, com o e-mail mascarado|RN09|Tela 03|
Linha 209: Linha 211:
 |06.1|O sistema exibe, inline no card, o alerta "Deseja parar de acompanhar este processo?" com os botões "Confirmar" e "Cancelar"|RN11|Tela 03| |06.1|O sistema exibe, inline no card, o alerta "Deseja parar de acompanhar este processo?" com os botões "Confirmar" e "Cancelar"|RN11|Tela 03|
 |06.2|Usuário clica em "Cancelar": o sistema fecha a confirmação sem executar nenhuma ação|RN11| | |06.2|Usuário clica em "Cancelar": o sistema fecha a confirmação sem executar nenhuma ação|RN11| |
-|06.3|Usuário clica em "Confirmar": o sistema exibe spinner no item e executa a remoção|RN11|Tela 03|+|06.3|Usuário clica em "Confirmar": o sistema exibe spinner no item e executa a remoção, autenticada pelo **token de sessão** da própria tela|RN11 RN17|Tela 03|
 |06.4|O sistema remove o processo da lista sem recarregar a página e oculta o spinner| |Tela 03| |06.4|O sistema remove o processo da lista sem recarregar a página e oculta o spinner| |Tela 03|
 |06.5|Lista esvaziada: o sistema exibe o empty state automaticamente| |Tela 03| |06.5|Lista esvaziada: o sistema exibe o empty state automaticamente| |Tela 03|
Linha 219: Linha 221:
  
 ^Passo^Ação^Regra^Tela| ^Passo^Ação^Regra^Tela|
-|01|Usuário recebe o e-mail de notificação com link "Parar de receber este acompanhamento"| |E-mail 02|+|01|Usuário recebe o e-mail de notificação com link "Parar de acompanhar este processo"| |E-mail 02|
 |02|Usuário clica no link| | | |02|Usuário clica no link| | |
-|03|O sistema redireciona para ''/acompanhar-processo/cancelar?token={token}&processo={id}''| |Tela 04| +|03|O sistema redireciona para ''/acompanhar-processo/cancelar?hash={hash}&acompanhamento={idAcompanhamento}''|RN16 RN17|Tela 04| 
-|04|O sistema exibe o estado loading: "Processando cancelamento…" e valida o token|RN06|Tela 04|+|04|O sistema exibe o estado loading: "Processando cancelamento…" e valida o token de descadastro|RN06 RN16|Tela 04|
 |05|Token válido|RN06| | |05|Token válido|RN06| |
 |05.1|O sistema remove imediatamente o processo da lista de acompanhamentos do e-mail|RN06| | |05.1|O sistema remove imediatamente o processo da lista de acompanhamentos do e-mail|RN06| |
 |05.2|O sistema exibe o estado sucesso: "Acompanhamento cancelado" com o número do processo|RN06|Tela 04| |05.2|O sistema exibe o estado sucesso: "Acompanhamento cancelado" com o número do processo|RN06|Tela 04|
-|05.3|O sistema exibe o link "Ver todos os meus acompanhamentos" → ''/acompanhar-processo/gerenciar?token=...''|RN07|Tela 04|+|05.3|O sistema exibe o link "Solicitar link de gerenciamento" → ''/acompanhar-processo/gerenciar'' (sem token)|RN07 RN16|Tela 04|
 |06|Token inválido| | | |06|Token inválido| | |
-|06.1|O sistema exibe o estado erro: "Link inválido" com botão "Acessar painel de acompanhamentos"| |Tela 04|+|06.1|O sistema exibe o estado erro: "Link inválido" com botão "Solicitar link de gerenciamento"| |Tela 04| 
 + 
 +<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>
  
 ==== Fluxo 05 – Reenvio de Link de Gerenciamento ==== ==== Fluxo 05 – Reenvio de Link de Gerenciamento ====
Linha 246: Linha 252:
 ^ Regra ^ Descrição ^ ^ Regra ^ Descrição ^
 |RN01|**Validação de formato de e-mail** – O e-mail informado deve ser válido conforme o formato RFC 5322. E-mails inválidos bloqueiam o envio do formulário com mensagem de erro inline.| |RN01|**Validação de formato de e-mail** – O e-mail informado deve ser válido conforme o formato RFC 5322. E-mails inválidos bloqueiam o envio do formulário com mensagem de erro inline.|
-|RN02|**Token único do serviço, com validade de 48 horas** – O TCE-Push emite um único tipo de token, válido por 48 horas a partir do envio, utilizável nos fluxos de confirmação, gerenciamento e cancelamento. O token recebido em um e-mail é **reaproveitado** nos links das telas seguintes — não é emitido token novo a cada etapa. Após as 48 horas, o sistema exibe a mensagem de link inválido e o usuário deve solicitar novo link.|+|RN02|**Dois tipos de token, com finalidades distintas** – O TCE-Push emite: **(a) Token de sessão** – válido por 48 horas a partir do envio, emitido quando o usuário age (inscrição ou pedido de reenvio) e utilizável nos fluxos de confirmação e gerenciamento. É **reaproveitado** nos links das telas seguintes — não é emitido token novo a cada etapa. Após as 48 horas, o sistema exibe a mensagem de link inválido e o usuário deve solicitar novo link. **(b) Token de descadastro** – persistente e de escopo único, presente apenas no e-mail de notificação de movimentação (RN16). A separação existe porque o e-mail de movimentação não responde a uma ação do usuário: chega muito depois da inscrição, quando um token de 48 horas já expirou.|
 |RN03|**Confirmação obrigatória por inscrição (controle de abuso)** – Toda inscrição em um processo requer confirmação explícita por e-mail, independentemente de o endereço ter sido confirmado em processos anteriores. Como o serviço não possui autenticação, a confirmação por link é o único mecanismo que garante que apenas o titular do endereço pode ativar um vínculo processo/e-mail. Sem essa exigência, qualquer usuário poderia inscrever endereços de terceiros em processos arbitrários sem o consentimento do titular.| |RN03|**Confirmação obrigatória por inscrição (controle de abuso)** – Toda inscrição em um processo requer confirmação explícita por e-mail, independentemente de o endereço ter sido confirmado em processos anteriores. Como o serviço não possui autenticação, a confirmação por link é o único mecanismo que garante que apenas o titular do endereço pode ativar um vínculo processo/e-mail. Sem essa exigência, qualquer usuário poderia inscrever endereços de terceiros em processos arbitrários sem o consentimento do titular.|
 |RN04|**Vedação de inscrição duplicada** – O mesmo e-mail não pode ser inscrito duas vezes no mesmo processo. O sistema retorna a resposta JA_INSCRITO e exibe a mensagem: "Você já está acompanhando este processo".| |RN04|**Vedação de inscrição duplicada** – O mesmo e-mail não pode ser inscrito duas vezes no mesmo processo. O sistema retorna a resposta JA_INSCRITO e exibe a mensagem: "Você já está acompanhando este processo".|
 |RN05|**Existência do processo** – O número de processo informado deve existir no sistema antes de aceitar a inscrição. Processos inexistentes bloqueiam o cadastro com mensagem de erro.| |RN05|**Existência do processo** – O número de processo informado deve existir no sistema antes de aceitar a inscrição. Processos inexistentes bloqueiam o cadastro com mensagem de erro.|
 |RN06|**Cancelamento imediato via link** – O cancelamento acionado pelo link do e-mail é executado imediatamente após a validação do token, sem etapa de confirmação adicional. O processo é removido no mesmo request.| |RN06|**Cancelamento imediato via link** – O cancelamento acionado pelo link do e-mail é executado imediatamente após a validação do token, sem etapa de confirmação adicional. O processo é removido no mesmo request.|
-|RN07|**Escopo do cancelamento por link** – O link "Parar de receber este acompanhamento" presente nos e-mails remove apenas o processo referenciado naquele link. O link "Gerenciar meus acompanhamentos" dá acesso à lista completa.|+|RN07|**Escopo do cancelamento por link** – O link "Parar de acompanhar este processo" presente nos e-mails remove apenas o processo referenciado naquele link, e não concede nenhum outro acesso (RN16). O link "Solicitar link de gerenciamento" leva ao formulário que dá acesso à lista completa.|
 |RN08|**Resposta neutra no reenvio de link** – Ao solicitar reenvio do link de gerenciamento, o sistema sempre retorna a mensagem: "Se este endereço possui acompanhamentos ativos, você receberá o link de acesso em breve.", independentemente de o e-mail existir ou não na base de dados.| |RN08|**Resposta neutra no reenvio de link** – Ao solicitar reenvio do link de gerenciamento, o sistema sempre retorna a mensagem: "Se este endereço possui acompanhamentos ativos, você receberá o link de acesso em breve.", independentemente de o e-mail existir ou não na base de dados.|
-|RN09|**Uso múltiplo dentro da validade** – O token pode ser utilizado múltiplas vezes, em qualquer dos fluxos, enquanto estiver dentro das 48 horas de validade (RN02). O reenvio do link de gerenciamento não invalida os tokens já emitidos e ainda válidos.|+|RN09|**Uso múltiplo dentro da validade** – O **token de sessão** pode ser utilizado múltiplas vezes, em qualquer dos fluxos, enquanto estiver dentro das 48 horas de validade (RN02). O reenvio do link de gerenciamento não invalida os tokens já emitidos e ainda válidos.|
 |RN10|**Sem limite de processos por e-mail** – Não há limite máximo de processos que podem ser associados a um único e-mail.| |RN10|**Sem limite de processos por e-mail** – Não há limite máximo de processos que podem ser associados a um único e-mail.|
 |RN11|**Confirmação antes de remover na tela de gerenciamento** – Na página de gerenciamento, ao clicar em "Parar de acompanhar", o sistema exibe uma confirmação inline no card do processo com os botões "Confirmar" e "Cancelar". A remoção só é executada após o usuário clicar em "Confirmar".| |RN11|**Confirmação antes de remover na tela de gerenciamento** – Na página de gerenciamento, ao clicar em "Parar de acompanhar", o sistema exibe uma confirmação inline no card do processo com os botões "Confirmar" e "Cancelar". A remoção só é executada após o usuário clicar em "Confirmar".|
Linha 260: Linha 266:
 |RN14|**Paginação na tela de gerenciamento** – Como não há limite máximo de processos por e-mail (RN10), a lista de acompanhamentos da Tela 03 é paginada em **12 processos por página**, exibindo o componente de paginação somente quando esse total é ultrapassado. O tamanho da página é **fixo** — não há seletor de itens por página. Reaproveita o componente ''Pagination'' já utilizado em ''/processos'' (mesmo padrão visual e de navegação).| |RN14|**Paginação na tela de gerenciamento** – Como não há limite máximo de processos por e-mail (RN10), a lista de acompanhamentos da Tela 03 é paginada em **12 processos por página**, exibindo o componente de paginação somente quando esse total é ultrapassado. O tamanho da página é **fixo** — não há seletor de itens por página. Reaproveita o componente ''Pagination'' já utilizado em ''/processos'' (mesmo padrão visual e de navegação).|
 |RN15|**Conformidade de acessibilidade** – Todas as telas do RF-008 seguem a diretriz **e-MAG 3.1** adotada pelo Portal. São verificáveis, em cada tela: nome acessível dos controles e dos campos, contraste mínimo do texto e dos elementos de interface, e aumento de fonte/zoom até 200% sem perda de conteúdo ou de função.| |RN15|**Conformidade de acessibilidade** – Todas as telas do RF-008 seguem a diretriz **e-MAG 3.1** adotada pelo Portal. São verificáveis, em cada tela: nome acessível dos controles e dos campos, contraste mínimo do texto e dos elementos de interface, e aumento de fonte/zoom até 200% sem perda de conteúdo ou de função.|
 +|RN16|**Token de descadastro** – Gerado **na confirmação da inscrição**, na mesma requisição que cria a linha de acompanhamento, e vinculado a ela (`PROACPR_ID`). É **persistente** (não expira), de **escopo único** — remove exclusivamente o acompanhamento a que se refere — e **não concede acesso ao painel de gerenciamento**. É o único token presente no e-mail de notificação de movimentação. Garante o cancelamento em um clique, a qualquer tempo, sem expor a lista de processos acompanhados pelo endereço: um link de descadastro vazado custa uma inscrição, enquanto um link de gerenciamento vazado revelaria todos os interesses processuais daquela pessoa. **Materialização decidida:** coluna nova em `PRO_ACOMPANHAPROCESSO`, `DEFAULT NULL` para não impactar o schema existente, com hash MD5 derivado de GUID gerado no backend, exposta pela view `VPRO_ACOMPANHAMENTOPROCESSOS` para que a rotina de disparo apenas **leia** o valor ao montar o link, nunca o gere. Como a linha só é criada após a confirmação (RN03), a coluna preenchida passa a ser a marca de vínculo confirmado.|
 +|RN17|**Dois endpoints de cancelamento, um por origem** – A remoção de um acompanhamento é acionada por duas origens, cada uma com seu endpoint: o botão "Parar de acompanhar" da **tela de gerenciamento**, autenticado por **token de sessão**; e o link do **e-mail de movimentação**, autenticado pelo **hash de descadastro** somado ao ID do acompanhamento (RN16). Ambos executam a **mesma rotina de remoção** no banco — muda apenas a autenticação. A separação em dois endpoints garante por construção que o hash de descadastro não alcance outros acompanhamentos do mesmo endereço: o endpoint que o aceita resolve um único vínculo, identificado pelo próprio hash, e não recebe ID de processo nem de usuário.|
  
 ---- ----
Linha 271: Linha 279:
 ^ Tabela ^ Papel no legado ^ Reaproveitamento no novo modelo ^ ^ Tabela ^ Papel no legado ^ Reaproveitamento no novo modelo ^
 |`TCE_GO.PSH_USUARIOS`|Cadastro do usuário do serviço Push (nome, e-mail, senha, dados de contato, flag `Habilitado`)|**Reaproveitada como cadastro implícito.** Ao inscrever um e-mail em um processo (RN03), o backend deve verificar se já existe uma linha com aquele e-mail; se não existir, criar uma nova (cadastro invisível ao usuário); se já existir, **reutilizar o registro sem sobrescrever dados preexistentes** (RN12).| |`TCE_GO.PSH_USUARIOS`|Cadastro do usuário do serviço Push (nome, e-mail, senha, dados de contato, flag `Habilitado`)|**Reaproveitada como cadastro implícito.** Ao inscrever um e-mail em um processo (RN03), o backend deve verificar se já existe uma linha com aquele e-mail; se não existir, criar uma nova (cadastro invisível ao usuário); se já existir, **reutilizar o registro sem sobrescrever dados preexistentes** (RN12).|
-|`PRO_ACOMPANHAPROCESSO`|Tabela de associação entre `PSH_USUARIOS` (`PSHUSUA_ID`) e `PRO_AUTUACAO` (`PROAUTU_ID`) — representa "quais processos este usuário acompanha"|**Reaproveitada integralmente.** É exatamente a estrutura que already sustenta a lista exibida nas telas de Confirmação e Gerenciamento (RF-008). Não requer alteração de schema.|+|`PRO_ACOMPANHAPROCESSO`|Tabela de associação entre `PSH_USUARIOS` (`PSHUSUA_ID`) e `PRO_AUTUACAO` (`PROAUTU_ID`) — representa "quais processos este usuário acompanha"; a coluna `PROANDA_ID` funciona como fila de notificação pendente|**Reaproveitada, com uma coluna nova.** É exatamente a estrutura que sustenta a lista exibida nas telas de Confirmação e Gerenciamento (RF-008). **Requer uma coluna adicional** para o hash de descadastro (RN16) — MD5 derivado de GUID, `DEFAULT NULL` —, que também precisa ser exposta pela view `VPRO_ACOMPANHAMENTOPROCESSOS` para uso da rotina de disparo. As inscrições anteriores ao corte recebem o hash por //update// incremental, para não perderem o descadastro em um clique. Nenhuma outra alteração de schema é prevista.|
 |`PRO_AUTUACAO`|Tabela de processos autuados|**Reaproveitada apenas para leitura** (validação de existência do processo — RN05 — e composição dos dados exibidos: número, interessado, assunto, ano).| |`PRO_AUTUACAO`|Tabela de processos autuados|**Reaproveitada apenas para leitura** (validação de existência do processo — RN05 — e composição dos dados exibidos: número, interessado, assunto, ano).|
  
Linha 296: Linha 304:
 ^ Endpoint legado ^ Reaproveitamento no RF-008 ^ ^ Endpoint legado ^ Reaproveitamento no RF-008 ^
 |`POST api/push/login`|**Descontinuado.** Dependia de senha; o novo modelo não tem login.| |`POST api/push/login`|**Descontinuado.** Dependia de senha; o novo modelo não tem login.|
 +|Portal legado `/Push` (formulário de inscrição)|**Desligado no corte.** Encerra a criação de acompanhamentos por fora do fluxo de confirmação do RF-008, garantindo que toda linha nova de `PRO_ACOMPANHAPROCESSO` nasça com hash de descadastro (RN16).|
 |`POST api/push/email` (cadastro)|**Substituído** pelo cadastro implícito descrito acima — o novo `POST /api/push/inscrever` (PRD §7) deve criar o registro em `PSH_USUARIOS` internamente, sem expor os campos `Nome`/`Senha` ao cliente.| |`POST api/push/email` (cadastro)|**Substituído** pelo cadastro implícito descrito acima — o novo `POST /api/push/inscrever` (PRD §7) deve criar o registro em `PSH_USUARIOS` internamente, sem expor os campos `Nome`/`Senha` ao cliente.|
 |`GET api/push/verifica/{numeroProcesso}`|**Reaproveitável como base, com correção de parâmetro:** no RF-008 o parâmetro deve ser `idAutuacao`, não o número público — a página do processo (`/processo/{id}`) já tem o ID de autuação em contexto, o usuário não precisa informá-lo.| |`GET api/push/verifica/{numeroProcesso}`|**Reaproveitável como base, com correção de parâmetro:** no RF-008 o parâmetro deve ser `idAutuacao`, não o número público — a página do processo (`/processo/{id}`) já tem o ID de autuação em contexto, o usuário não precisa informá-lo.|
 |`PUT api/push/adiciona/processos`|**Reaproveitável como base, com a mesma correção:** a lista recebida deve conter IDs de autuação, não números de processo, antes de repassar para `WEB_PACKAGE.PWEB_ACOMPANHAPROCESSO` (que exigirá a conversão pontual citada acima).| |`PUT api/push/adiciona/processos`|**Reaproveitável como base, com a mesma correção:** a lista recebida deve conter IDs de autuação, não números de processo, antes de repassar para `WEB_PACKAGE.PWEB_ACOMPANHAPROCESSO` (que exigirá a conversão pontual citada acima).|
-|`DELETE api/push/remove/{numeroProcesso}`|**Reaproveitável como base:** apesar do nome do parâmetro na rota legada, o valor é repassado como ID interno para `RemoveAcompanhamentoDeProcesso`. No RF-008 o parâmetro deve se chamar explicitamente `idAutuacao`, para não sugerir que aceita o número público.|+|`DELETE api/push/remove/{numeroProcesso}`|**Reaproveitável como base** para `DELETE /api/push/cancelar`, usado pela tela de gerenciamento: apesar do nome do parâmetro na rota legada, o valor é repassado como ID interno para `RemoveAcompanhamentoDeProcesso`. No RF-008 o parâmetro deve se chamar explicitamente `idAutuacao`, para não sugerir que aceita o número público.| 
 +|— (não existe no legado)|**Desenvolvimento novo:** `DELETE /api/push/cancelar/email`, acionado pelo link do e-mail de movimentação. Recebe o hash de descadastro e o ID do acompanhamento (RN16, RN17), e executa a **mesma rotina de remoção** do endpoint acima — muda apenas a autenticação.|
 |`GET api/push/processos`|**Reaproveitável** como base para `GET /api/push/gerenciar`.| |`GET api/push/processos`|**Reaproveitável** como base para `GET /api/push/gerenciar`.|
 |Autenticação `BasicAuthorizationPush` (header `Authorization: Basic {id}@{tokenCriptografado}`, sem expiração — risco S4 do relatório técnico)|**Não reaproveitada.** O RF-008 exige token de e-mail com expiração (RN02) e sem exigência de login prévio; é necessário um mecanismo novo de emissão/validação de token (ex.: JWT com `exp`).| |Autenticação `BasicAuthorizationPush` (header `Authorization: Basic {id}@{tokenCriptografado}`, sem expiração — risco S4 do relatório técnico)|**Não reaproveitada.** O RF-008 exige token de e-mail com expiração (RN02) e sem exigência de login prévio; é necessário um mecanismo novo de emissão/validação de token (ex.: JWT com `exp`).|
Linha 309: Linha 319:
 |`smtp.tce.go.gov.br`|Host SMTP institucional, configurado via `SmtpClient` do .NET (`ServicoDeEmail.EnviaEmail`)|**Confirmado como servidor a ser utilizado.** Os três e-mails do RF-008 (seção "E-mails Enviados") devem ser despachados por este host, seguindo o mesmo padrão do restante do portal.| |`smtp.tce.go.gov.br`|Host SMTP institucional, configurado via `SmtpClient` do .NET (`ServicoDeEmail.EnviaEmail`)|**Confirmado como servidor a ser utilizado.** Os três e-mails do RF-008 (seção "E-mails Enviados") devem ser despachados por este host, seguindo o mesmo padrão do restante do portal.|
 |`push@tce.go.gov.br`|—|**Endereço de remetente institucional definido para o RF-008.** Utilizado no campo `From` do `DtoEmail` para os três e-mails (Confirmação, Notificação, Reenvio).| |`push@tce.go.gov.br`|—|**Endereço de remetente institucional definido para o RF-008.** Utilizado no campo `From` do `DtoEmail` para os três e-mails (Confirmação, Notificação, Reenvio).|
 +
 +==== Mecanismo de Disparo da Notificação (legado) ====
 +
 +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:
 +
 +  - **Enfileiramento (imediato).** Todo registro de andamento gravado em `PRO_ANDAMENTO` marca, via //trigger//, as inscrições daquele processo como "pendentes de notificação".
 +  - **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**.
 +
 +=== Onde o template é implementado ===
 +
 +**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.
 +
 +=== Quais movimentações geram notificação ===
 +
 +  * **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.
 +
 +=== Sigilo — regra vigente (decidida) ===
 +
 +**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.//
 +
 +=== Decisões de negócio pendentes ===
 +
 +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:
 +
 +^ Tema ^ Comportamento atual do legado ^ Decisão necessária ^
 +|**Granularidade**|Se o processo se movimenta duas vezes dentro da janela de 3 minutos, **apenas a última movimentação é notificada** — a anterior é descartada silenciosamente. É efeito colateral da implementação, não regra deliberada.|Definir se cada movimentação gera um e-mail, ou se movimentações próximas são consolidadas em uma única notificação.|
 +|**Escopo do "desabilitado"**|O indicador de habilitação vive no **usuário**, não na inscrição. Desabilitar um e-mail interrompe as notificações de **todos** os processos daquela pessoa de uma só vez.|O novo modelo exige controle **por inscrição** (RN03 e Fluxo 04) — não há como cancelar um processo isoladamente reaproveitando o indicador atual.|
 +|**Confiabilidade do envio**|Falhas de envio são descartadas sem registro, e não existe histórico de e-mails enviados. Uma notificação perdida é indetectável e irrecuperável.|Definir se o RF-008 exige registro de envio e reenvio automático em caso de falha.|
 +|**Tratamento especial de uma conta**|Uma regra fixa no banco, acionada a cada autuação nova, dá tratamento diferenciado às inscrições de **uma conta identificada por ID literal**, atualizando o campo de andamento delas. Não cria acompanhamentos — a criação é exclusiva do fluxo de confirmação.|Confirmar a quem a regra pertence e se deve ser preservada. O RF-008 não depende dela, mas quem alterar o mecanismo de disparo precisa saber que existe.|
  
 ==== Riscos e Pontos de Atenção para o Backend ==== ==== Riscos e Pontos de Atenção para o Backend ====
Linha 322: Linha 373:
  
 ^ Data ^ Alteração ^ Motivo ^ ^ Data ^ Alteração ^ Motivo ^
 +|2026-09-06|RN16 — hash gerado **na confirmação** (não na inscrição), coluna `DEFAULT NULL`; registrados o //update// incremental para a base existente e o desligamento do portal legado `/Push` no corte|Decisões do time. A linha só nasce após a confirmação, o que torna a coluna preenchida a marca de vínculo confirmado; sem a migração, a base antiga perderia o descadastro em um clique que o e-mail legado já oferece|
 +|2026-09-06|**Decisões técnicas registradas:** RN16 fixa a materialização do token (coluna nova em `PRO_ACOMPANHAPROCESSO`, MD5 de GUID, exposta na view); RN17 passou de endpoint único para **dois endpoints**, um por origem; parâmetros do link de cancelamento passaram de `token`+`processo` para `hash`+`acompanhamento`|Decisões do time em 06/09/2026. A separação em dois endpoints substitui, por construção, a verificação de escopo que o endpoint único exigiria; o ID do acompanhamento (`PROACPR_ID`) identifica o vínculo diretamente, em vez do ID do processo|
 +|2026-09-06|**RN17 acrescentada** — cancelamento aceita os dois tipos de token, em endpoint único, com escopo determinado pelo tipo; Fluxo 03 passo 06.3 passou a citá-la|A tela de gerenciamento precisa cancelar acompanhamentos com o token de sessão, o que a RN16 não cobria. A regra também explicita que o processo informado na requisição é ignorado quando o token é de descadastro — sem isso, um link vazado alcançaria outros acompanhamentos do mesmo endereço|
 +|2026-09-06|**RN02 desdobrada em dois tipos de token** (sessão, 48h; descadastro, persistente) e **RN16 acrescentada**; E-mail 02, RN07, RN09 e Fluxo 04 alinhados|O e-mail de movimentação não responde a uma ação do usuário — chega muito depois da inscrição, quando um token de 48h já expirou, e é montado por rotina que não emite tokens. Além disso, o link de gerenciamento expõe toda a lista de processos do endereço, exigindo escopo de segurança distinto do link de cancelamento|
 +|2026-09-06|E-mail 02 — corpo passou a incluir **Órgão ou Setor Atual**, **Data Autuação** e **Ano Referência**; link "Gerenciar meus acompanhamentos" renomeado para **"Solicitar link de gerenciamento"** e sem token|Decisão de Requisitos sobre o conteúdo da notificação; o rótulo anterior prometia acesso direto ao painel, que deixou de ocorrer no clique|
 +|2026-09-06|Registrado que **o template do E-mail 02 é implementado em PL/SQL**, onde ocorre o disparo; `PRO_ACOMPANHAPROCESSO` pode requerer coluna adicional|Decisão de Requisitos; a afirmação anterior de que a tabela não requeria alteração de schema deixou de ser incondicional com a RN16|
 +|2026-09-06|**Acrescentada a subseção "Mecanismo de Disparo da Notificação (legado)"**, com as movimentações que geram notificação e cinco decisões de negócio pendentes|O disparo do e-mail de movimentação não estava especificado; a engenharia reversa do banco (PRD §12) revelou comportamentos — sigilo, granularidade, escopo do "desabilitado" — que são regra de negócio e não estavam documentados como decisão|
 |2026-08-31|Tela 01 e Fluxo 01 passo 05.1 — a mensagem "Informe um e-mail válido." passou a cobrir também o campo não preenchido, exibida abaixo do rótulo|Decisão de Requisitos; o comportamento do campo obrigatório não estava especificado (PD-02)| |2026-08-31|Tela 01 e Fluxo 01 passo 05.1 — a mensagem "Informe um e-mail válido." passou a cobrir também o campo não preenchido, exibida abaixo do rótulo|Decisão de Requisitos; o comportamento do campo obrigatório não estava especificado (PD-02)|
 |2026-08-31|Fluxo 01 — passos 10 e 10.1 renumerados para 09 e 09.1|Lacuna de numeração corrigida a pedido de Requisitos (PD-13)| |2026-08-31|Fluxo 01 — passos 10 e 10.1 renumerados para 09 e 09.1|Lacuna de numeração corrigida a pedido de Requisitos (PD-13)|
Linha 336: Linha 394:
 //Gerado com: documentar-funcionalidade-v1.md// \\ //Gerado com: documentar-funcionalidade-v1.md// \\
 //Revisado por: Paulo Ricardo Amorim Silva - pramorim@tce.go.gov.br// //Revisado por: Paulo Ricardo Amorim Silva - pramorim@tce.go.gov.br//
- 
  • pres/gerti/gestao_de_ativos/portal/er_008.1788207848.txt.gz
  • Última modificação: 31/08/2026 20:24
  • por pramorim