F08 — Gerenciar templates de notificações

IT2 Concluída · Rastreabilidade: F08 · CP9 · OE3

Issue da Feature (GitHub): #180 — abrir no GitHub

Protótipo: Protótipo V2 (IT1) — está na seção de notificações do protótipo geral do painel administrativo.

Deploy: link a definir

Acesso para avaliação

Esta funcionalidade exige login de administrador.

E-mail: owner@crianex.com · Senha: Crianex@Owner1

Refinamento pós-implementação

RF63 foi adicionado após a entrega inicial (seleção de tipo por catálogo fixo + cor personalizável por template). O AC de RF15 também foi revisado: o bloqueio de duplicidade por tipo de evento (409) foi substituído por ativação automática com substituição do template anterior. Detalhamento completo em Resultados V&V da IT2 — MR.03/MR.04.

Requisitos (evidências)

Selecione um requisito na navegação abaixo. Cada um traz seus critérios de aceite, regras de negócio e um espaço para o screenshot da funcionalidade em funcionamento (substitua a imagem de placeholder pela captura real).

RF15

RF15 — Adicionar template de notificações

Critérios de aceite (BDD)

• Dado admin autenticado com dados válidos, quando criar template, então é persistido e associado a um tipo de evento.
• Dado campos obrigatórios vazios (nome, conteúdo ou evento), quando submeter, então a validação impede a criação e sinaliza os campos.
• Dado tipo de evento que já possui um template ativo, quando criar outro template para o mesmo evento, então o template anterior é desativado automaticamente e o novo passa a ser o único ativo para aquele tipo (ativação automática por substituição, sem exigir remoção manual prévia). Critério revisado
• Dado requisição sem permissão, quando POST do template, então o RLS bloqueia com 403.

Regras de negócio: RN14 — Template de notificação por evento, com fallback para o template padrão · RN25 — Ativação exclusiva de template por tipo de evento

Evidência (screenshot):

Deploy: link a definir

RF56

RF56 — Editar template de notificações

Critérios de aceite (BDD)

• Dado template existente, quando editar, então os dados são atualizados sem duplicar o registro.
• Dado campos inválidos na edição, quando submeter, então a validação impede e a versão anterior é mantida.
• Dado template inexistente ou removido, quando editar, então retorna 404 sem efeito.
• Dado requisição sem permissão, quando PATCH do template, então o RLS bloqueia com 403.

Regras de negócio: RN14 — Template de notificação por evento, com fallback para o template padrão

Evidência (screenshot):

Deploy: link a definir

RF57

RF57 — Remover template de notificações

Critérios de aceite (BDD)

• Dado template existente, quando remover, então é excluído e não é mais usado em novos disparos.
• Dado remoção, quando acionada, então exige confirmação explícita antes de excluir.
• Dado template vinculado a evento ativo, quando removido, então novos disparos caem para o template de fallback padrão sem quebrar o envio.
• Dado template já removido, quando remover novamente, então retorna 404 de forma idempotente.
• Dado requisição sem permissão, quando DELETE do template, então o RLS bloqueia com 403.

Regras de negócio: RN14 — Template de notificação por evento, com fallback para o template padrão

Evidência (screenshot):

Deploy: link a definir

RF63

RF63 — Personalizar cor e tipo de template de notificação

Novo — refinamento pós-implementação

Critérios de aceite (BDD)

• Dado o formulário de criação/edição de template, quando o admin abre o campo "tipo de evento", então as opções são carregadas de um catálogo fixo de tipos, não um campo de texto livre.
• Dado um tipo de evento do catálogo ainda não implementado no sistema, quando exibido no seletor, então aparece desabilitado/acinzentado e não pode ser selecionado.
• Dado o formulário de template, quando o admin escolhe uma cor na paleta, então a cor é persistida e usada para destacar as notificações resultantes daquele tipo de evento na central de notificações.
• Dado nenhuma cor selecionada explicitamente, quando o template é salvo, então a cor sugerida do catálogo para aquele tipo é aplicada como padrão.

Regras de negócio: RN25 — Ativação exclusiva de template por tipo de evento · RN26 — Catálogo fixo de tipos de notificação

Evidência (screenshot):

Deploy: link a definir

RNF03

RNF03 — Tempo de resposta da área administrativa

Classificação: Eficiência
Descrição: 95% das operações de leitura no painel administrativo (listagens, dashboards, detalhes de registro) retornam em até 2 segundos, do disparo da requisição HTTP à resposta completa da API, sob carga normal de uso (≤ 10 usuários simultâneos).

Evidência (screenshot):

Verificação: Resultados V&V da IT2

RNF09

RNF09 — Controle de acesso por linha (RLS)

Classificação: Segurança
Descrição: Toda tabela com dados sensíveis (clientes, leads, notificações, membros) tem política de Row Level Security ativa no banco, restringindo leitura/escrita ao perfil autorizado mesmo em acesso direto ao banco; verificado por teste com credencial de perfil não autorizado.

Evidência (screenshot):

Verificação: Resultados V&V da IT2

DoR

Definition of Ready — Evidências

Checklist do DoR aplicado à F08 antes de entrar em execução. Todos os itens foram atendidos conforme o critério definido em DoR e DoD.

Critério DoR	Status	Evidência
Título no padrão FDD <ação> <resultado> <de/para/no/com> <objeto>	✅	Issue #180 — título conforme o padrão
Critérios de aceite escritos e verificáveis (Given/When/Then)	✅	Ver abas RF/RNF desta página — todos os cenários BDD documentados
Estimativa registrada: VB, CX e IP calculados	✅	Priorização do Backlog — coluna IP da tabela de features
Dependências identificadas; bloqueantes resolvidos	✅	Mapa de Dependências — IT2 — bloqueantes verificados antes do início
Class Owner designado e linkada à Feature parent e à CP de origem	✅	Issue #180 — assignees e labels de CP/Feature registrados
Protótipo revisado pelo cliente	✅	Protótipo CRM (IT2)
Technical Design Review (TDR) concluída	✅	Design Técnico IT2
Ao menos um critério de segurança ou usabilidade identificado	✅	Ver aba RNF desta página

DoD

Definition of Done — Evidências

Checklist do DoD verificado ao encerrar a F08. Todos os itens foram atendidos antes de mover a issue para Done no Kanban.

Critério DoD	Status	Evidência
Critérios de aceite validados (BDD cobertos)	✅	Issue #180 — evidências anexadas na descrição da issue
Testes automatizados passando (unitários + integração)	✅	Issue #180 — evidências anexadas na descrição da issue
Lint sem erros e formatação OK (ESLint + Prettier)	✅	Issue #180 — evidências anexadas na descrição da issue
CI verde (build + testes + lint)	✅	Issue #180 — evidências anexadas na descrição da issue
PR aprovado por Chief Programmer ou Project Manager	✅	Issue #180 — PR de resolução com approve registrado
Migration de banco aplicada	✅	Issue #180 — evidências anexadas na descrição da issue
Sem vulnerabilidades críticas (SAST/linting de segurança)	✅	Issue #180 — evidências anexadas na descrição da issue
Validação parcial do cliente registrada	✅	Validação Parcial IT2
Validação Formal aprovada pelo cliente	✅	Validação Formal IT2
Rastreabilidade atualizada	✅	Tabela de Requisitos — RF/RNF vinculados
Issue movida para Done no GitHub Projects	✅	Issue #180 — fechada via merge do PR (closes #N)