Comunicação — visão geral

O módulo de Comunicação documenta o que o frontend (Angular) do Portal 2.0 tem, hoje, para fluxos disparados por e-mail. É pouco: uma única tela própria — a página pública onde a pessoa convidada aceita um convite — e nenhuma tela dedicada para o restante das capacidades de e-mail que o backend já expõe (criar/reenviar/revogar convite, enviar laudo por e-mail). Este levantamento cobre exatamente os dois caminhos de código indicados para a tarefa: src/app/shared/api e src/app/pages/invitation-accept, no repositório mm-pacs-portal-main-interface, branch integration/with-fixlaudo, testado no ambiente https://task4.srv1812538.hstgr.cloud/.

O que existe de tela

Tela	Rota	Cobertura
Aceitar convite por e-mail	/invitations/accept?token=...	Única tela deste módulo — pública, sem login

Não existe, no código desta branch, nenhuma tela para criar, reenviar ou revogar um convite (confirmado: nenhum arquivo em src/app/pages ou src/app/features chama POST /v1/invitations — grep por invitations fora de invitation-accept/shared/auth/invitation não encontra nenhuma outra referência de produção). Essas operações — documentadas em Convite de usuário — API — hoje só existem via chamada direta à API. O mesmo vale para o envio de laudo por e-mail: no módulo de exames existe um dialog de alteração de status de laudo em lote (ExamBatchReportStatusDialogComponent) que avisa o usuário quando o status escolhido (PENDING/RECALL) dispara um e-mail no backend (ReportEmailRequestedEvent), mas nenhuma tela lida neste levantamento chama diretamente a rota POST /exams/:id/report-emails (essa rota está fora do escopo de shared/api e pages/invitation-accept — mencionada aqui só para deixar claro que ela existe e tem outro gatilho). Ver Enviar laudo por e-mail — API.

O que shared/api expõe sobre isso

Nada específico de comunicação/notificação. src/app/shared/api (ver index.ts) é infraestrutura HTTP genérica e reutilizada por praticamente toda a aplicação: ApiService (wrapper fino de HttpClient com base URL), GraphqlService, ErrorHandlerService/errorInterceptor (tratamento uniforme de erro e toasts), StandardApiError, upload com URL pré-assinada, leitor de asset público, etc. Não há um NotificationApiService nem qualquer arquivo com "notification"/"email" no nome dentro dessa pasta.

O único serviço deste levantamento que fala com o backend de convites — AuthInvitationService (src/app/shared/auth/invitation/auth-invitation.service.ts) — não mora em shared/api (mora em shared/auth) e não usa o ApiService genérico: ele injeta HttpClient diretamente e monta a URL na mão (${environment.apiUrl}/v1/invitations/accept). Isso faz sentido porque as duas chamadas que ele faz são públicas (sem token) — mas ele ainda passa pelo errorInterceptor global (registrado para todo HttpClient da aplicação, não só via ApiService), que aplica retry automático (1 tentativa, GET apenas) em erro de rede/5xx e trata alguns 401 especiais. Isso é relevante para esta tela porque /invitations/accept não está na lista AUTH_URL_FRAGMENTS de error.interceptor.ts — ao contrário de /email/verify e /recovery-email/confirm, que estão. Na prática isso não chega a ser um problema: o backend responde token inválido/expirado/revogado com 400 IDENTITY_INVITATION_UNAVAILABLE (não 401) — confirmado ao vivo (ver Aceitar convite por e-mail) — então os ramos de "sessão expirada" do interceptor nunca chegam a disparar para esta tela. Fica registrado como detalhe técnico, não como bug: se um dia o backend passar a devolver 401 genérico nessa rota, o interceptor tentaria (incorretamente) tratar como sessão expirada.

Backend correspondente

Duas páginas de API cobrem, juntas, o que esta tela consome e o que a viabiliza:

• Convite de usuário — API (módulo Usuário, não Notification) — contrato completo de GET/POST /v1/invitations/accept/:token, que é o que a tela realmente chama.
• Notification (e-mail) — visão geral (módulo Notification) — a infraestrutura compartilhada de envio de e-mail (shared/module/email) que o backend usa para disparar o e-mail de convite (via IdentityEmailTemplateCatalog, citado nesse documento como consumidor da infra). A tela documentada aqui não dispara esse envio — ela só inspeciona e aceita um convite que já foi enviado por outro fluxo (a criação do convite, sem tela no front desta branch).

Contexto de negócio (legado) — Bitrix

Os cards abaixo (funil de features do sistema legado, entityTypeId 1320, categoria "Notification") descrevem a intenção de produto original da comunicação por e-mail. Não são fonte de comportamento atual — o código atual (branch integration/with-fixlaudo) é uma reescrita: sem Mailgun, sem tb_fila_email, sem templates por idioma/país, como já registrado em Notification — visão geral (back), seção "Sobre o legado". Nenhum dos dois cards tem tela equivalente no código atual — o card F-S02 (laudo por e-mail) virou uma rota de API sem UI dedicada de disparo (fora de mudar o status do laudo); o card F-S03 (e-mails de ciclo de vida de conta) hoje é só o convite de usuário, que é a única peça com tela. Listados aqui como contexto histórico, só id e título:

Card	Título
802	F-S02 — Enviar laudo ao paciente/solicitante por e-mail - Front
806	F-S03 — Notificar ciclo de vida de acesso/conta por e-mail - Front

Páginas deste módulo

Página	Cobre
Aceitar convite por e-mail	InvitationAcceptComponent — única tela pública deste módulo

Relacionado

• ⚙️ API: Convite de usuário
• ⚙️ API: Notification (e-mail) — visão geral
• ⚙️ API: Enviar laudo por e-mail
• 🖥️ Aceitar convite por e-mail