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) |
| 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 |
| 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.