ADR-0011 — Estratégia de Comunicações

Status

Proposto

Contexto

O sistema EBDbe precisa de canais de comunicação para:

Ativação manual de contas: avisar aprovadores quando há solicitante aguardando; avisar solicitante do resultado (ADR-0010)
Coordenação entre participantes: superintendentes, secretários, professores, alunos
Notificações operacionais: lembretes, alertas, informações da unidade
Comunicação publicitária e informativa: site (visitantes, usuários, qualificados)
Comunicações urgentes: situações que exigem prioridade sobre demais avisos

As comunicações devem respeitar a hierarquia organizacional (ADR-0002), o modelo de acesso (ADR-0003) e a privacidade (ADR-0006). É fundamental definir regras claras de destino e permissão antes da implementação.

Decisão

O sistema adotará estratégia de comunicações em quatro tipos:

Instantânea — notificação em tempo (ou quase) real
Email — assíncrona, com as mesmas regras de destino
Site — pública, gerenciada e específica (para visitantes, usuários e qualificados)
Urgente — prioridade máxima sobre outras comunicações

O backend será autoridade para validação de destinatários e permissões. Todas as comunicações estarão sujeitas a validação de escopo (ministry_id, unit_id) e papel do remetente.

Políticas de Mensagens

Tipo	Política
Instantânea	Observar o previsto neste ADR (seções 1.x)
Email	Observar o previsto neste ADR (seções 2.x)
Site	Ver seção 4 (tipos público, gerenciado, específico)
Urgente	Ver seção 5 (usuários e grupos qualificados)

1. Tipo: Mensagem Instantânea

Notificação entregue em tempo (ou quase) real, exibida no sistema (PWA) e/ou via push.

1.1 Destinos Permitidos

Destino	Descrição	Exemplo
Pessoa	Um usuário específico	user_id
Grupo	Conjunto definido (ex.: ClassGroup)	Todos da classe Juniores
Nível	Por posição na árvore hierárquica	Todas as igrejas do ministério
Perfil	Por Role	Todos EBD_SUPERINTENDENT da unit

1.2 Regras de Envio

Remetente deve ter permissão de leitura sobre o escopo dos destinatários.
Escopo: ministry_id, unit_id (e hierarquia). LOCAL_SECRETARY envia para sua unit e filhas; MINISTRY_ADMIN para todo o ministério.
Validação no backend antes do envio.

1.3 Infraestrutura

Firebase Cloud Messaging (FCM) ou equivalente. O sistema armazenará preferências de canal (receber/não receber) por usuário. Essas preferências integram o perfil de usuário por tenant (ADR-0013).

2. Tipo: Mensagem por Email

Mesma lógica de destino da mensagem instantânea.

2.1 Destinos

Pessoa, Grupo, Nível, Perfil (idênticos à seção 1)

2.2 Regras de Envio

Mesmas regras de escopo e permissão da mensagem instantânea.
Email é assíncrono; adequado para auditoria, lembretes e notificações que precisam persistir fora do sistema.

2.3 Privacidade

Consentimento para recebimento de emails (conforme ADR-0006).
Opt-in para comunicações promocionais/informativas; opt-out possível para não essenciais.
Emails de transação (ex.: ativação de conta, resultado de aprovação) são essenciais e não opt-out.

3. Modalidade: Mensagem Entre Participantes (P2P)

Comunicação de usuário para usuário(s), com regras mais restritivas. Utiliza canais instantâneo e/ou email conforme destino e preferências.

3.1 Destinos Permitidos

Destino	Descrição	Restrição
Pessoa	Um usuário específico	Mesmo escopo ou abaixo
Grupo	Grupo do qual o remetente participa	Ex.: mesma ClassGroup
Mesmo nível	Usuários da mesma unit ou mesmo patamar hierárquico no ramo	Não superior
Mesmo perfil	Usuários com o mesmo Role	Ex.: professor p/ professor
Abaixo	Usuários em nível hierárquico inferior	Na mesma unit ou filhas

3.2 Restrições

Não enviar para nível superior (evita sobrecarga de superiores).
Não enviar para fora do escopo do remetente.
“Abaixo” = mesma unit ou unit filha, com Role de nível maior (menor poder).

3.3 Casos de Uso

Professor comunica turma.
Secretário comunica superintendente.
Aluno envia dúvida ao professor.
Superintendente comunica professores da unidade.

4. Tipo: Comunicação via Site

Comunicação publicitária e informativa exibida no site/webapp do sistema, com três níveis de alcance e permissão.

4.1 Público Geral (Visitantes)

Destino: visitantes (não autenticados) ou qualquer pessoa que acessa o site.
Conteúdo: comunicação publicitária geral.
Permissão: gerenciada por MINISTRY_ADMIN ou equivalente.
Exemplo: avisos de eventos abertos, boas-vindas, promoções gerais.

4.2 Gerenciada para Usuários

Destino: usuários autenticados.
Conteúdo: comunicação publicitária e informativa gerenciada.
Permissão: escopo por ministry_id e unit_id conforme RBAC.
Exemplo: avisos da unidade, lembretes de reuniões, informações da EBD.

4.3 Gerenciada para Qualificados

Destino: usuários com perfil qualificado (ex.: professores, superintendentes, secretários).
Conteúdo: comunicação publicitária e informativa gerenciada.
Permissão: filtrada por Role e escopo organizacional.
Exemplo: orientações para professores, atualizações curriculares, comunicados dirigidos.

5. Tipo: Comunicações Urgentes

Comunicação com prioridade máxima, destinada a usuários e/ou grupos qualificados.

5.1 Características

Destino: usuários específicos e/ou grupos qualificados.
Prioridade: sobressai sobre todas as outras comunicações.
Canal: pode combinar instantânea, email e exibição destacada no site conforme configuração.
Exemplo: alteração de última hora em evento, aviso de segurança, cancelamento urgente.

5.2 Regras

Remetente deve ter permissão adequada para envio de comunicações urgentes.
Validação no backend; possível exigir confirmação de segundo fator para envio.
Avisos urgentes sempre exibidos em destaque (ver seção 7).

6. Matriz de Destinos por Tipo

Tipo	Pessoa	Grupo	Nível	Perfil	Abaixo
Instantânea	Sim	Sim	Sim	Sim	Não
Email	Sim	Sim	Sim	Sim	Não
Site (público)	—	—	—	—	—
Site (usuários)	Sim	Sim	Sim	Sim	Não
Site (qualificados)	Sim	Sim	Sim	Sim	Não
Urgente	Sim	Sim	Sim	Sim	Conforme escopo
Entre participantes	Sim	Sim	Sim	Sim	Sim

7. Avisos e Configurações de Preferência

Os avisos devem ocorrer e ter configurações de preferência nos seguintes tipos:

7.1 Instantânea

Canal de entrega: mensagem no celular bloqueado (push), na lista de notificações e aviso no sininho do app.
Preferências: habilitar/desabilitar push, som, vibração.
Persistência: histórico na lista do app.

7.2 Email

Preferências: opt-in/opt-out conforme ADR-0006 (exceto mensagens essenciais).
Formato: respeitar template e assinatura configurados.

7.3 Site

Destaque: mensagens não visualizadas devem ter destaque visual (indicador, badge, prioridade na listagem).
Preferências: quais categorias exibir, ordem de exibição.
Marcação: possibilidade de marcar como lido/não lido.

7.4 Comunicações Urgentes

Prioridade: devem sobresair sobre outras comunicações (ex.: overlay, banner fixo, notificação bloqueando interação).
Não opt-out: avisos urgentes não podem ser desativados pelo usuário (exceto conforme política de segurança).
Canal: sempre visível no site e, quando aplicável, via instantânea e/ou email.

8. Integração com Ativação Manual (ADR-0010)

O fluxo de ativação manual depende das comunicações:

8.1 Quando Solicitante Cadastra (status PENDING)

Sistema identifica aprovadores.
Envia notificação instantânea aos aprovadores: “Solicitante X aguarda sua aprovação na unit Y. [Link]”
Envia email aos aprovadores com o mesmo conteúdo.
Sem essa notificação, o fluxo de ativação manual não funciona.

8.2 Quando Aprovador Decide

Se aprovado: notificação (instantânea + email) ao solicitante: “Sua conta foi ativada.”
Se rejeitado: notificação ao solicitante com a decisão (motivo opcional).

9. Integração com RBAC (ADR-0003)

9.1 Permissão de Envio

Quem envia mensagem “de sistema” (instantânea ou email para múltiplos): deve ter permissão READ sobre o escopo dos destinatários.
Quem envia mensagem entre participantes: regras da seção 3 (P2P).

9.2 Validação no Backend

Antes de enviar, o backend valida:

Remetente autenticado
Destinatários resolvidos (lista de user_ids)
Remetente tem permissão para alcançar cada destinatário
Escopo (ministry_id, unit_id) respeitado

10. Privacidade e Consentimento

Referência: ADR-0006 (Política de Privacidade).
Preferências de canal por usuário: receber instantâneas, receber emails, receber do site, urgentes.
Comunicações essenciais (ativação, segurança, transação) não são opt-out.
Logs de envio para auditoria, sem expor conteúdo sensível além do necessário.

11. Modelo Conceitual Simplificado

Message (genérico)
├── type: INSTANT | EMAIL | SITE | URGENT | PARTICIPANT
├── sender_id
├── recipient_type: USER | GROUP | LEVEL | PROFILE | BELOW
├── recipient_ids[] (resolvidos)
├── ministry_id, unit_id (escopo)
├── subject / body
└── created_at

NotificationPreferences (por User)
├── receive_instant: boolean
├── receive_email: boolean
├── receive_site: boolean
├── receive_urgent: boolean (não opt-out em geral)
├── instant_push_locked: boolean (celular bloqueado)
├── instant_app_bell: boolean (sininho)
└── ...

As preferências são vinculadas ao perfil de aplicação do usuário no tenant (ministry_id) e não concedem permissão adicional de acesso.

Consequências

Infraestrutura de mensageria necessária (FCM, serviço de email).
Backend valida destinatários e permissões antes de todo envio.
Ativação manual depende da implementação das notificações.
Preferências de canal devem ser respeitadas.
Site requer área de comunicação publicitária/informativa com níveis de acesso.
Comunicações urgentes exigem tratamento prioritário em UI e backend.
Alterações nas regras de comunicação exigirão novo ADR.