F20 — Gerenciar colunas do funil
IT2 Concluída · Rastreabilidade: F20 · CP1 · OE3
Issue da Feature (GitHub): #176 — abrir no GitHub
Protótipo: Protótipo CRM (IT2) — compartilhado entre F19, F20 e F21 (mesmo board Kanban).
Deploy: link a definir
Esta funcionalidade exige login de administrador.
E-mail: owner@crianex.com · Senha: Crianex@Owner1
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).
- RF38
- RF39
- RF40
- RNF01
- RNF09
- RNF22
- DoR
- DoD
RF38 — Adicionar colunas no CRM
Critérios de aceite (BDD)
- Dado admin autenticado, quando adicionar coluna, então uma nova coluna é criada no funil e persistida.
- Dado nome de coluna vazio ou duplicado, quando submeter, então a validação impede a criação.
- Dado requisição sem permissão, quando POST da coluna, então o RLS bloqueia com 403.
Regras de negócio: —
Evidência (screenshot):
Deploy: link a definir
RF39 — Remover colunas no CRM
Critérios de aceite (BDD)
- Dado coluna existente sem cards, quando remover, então a coluna é excluída do funil.
- Dado coluna padrão ou com cards, quando tentar remover, então a remoção é impedida ou exige realocação dos cards (invariante de board não vazio).
- Dado remoção, quando acionada, então exige confirmação antes de excluir.
Regras de negócio: RN21 — Integridade do funil (board sempre com ao menos uma coluna; coluna com cards exige realocação)
Evidência (screenshot):
Deploy: link a definir
RF40 — Editar colunas no CRM
Critérios de aceite (BDD)
- Dado coluna existente, quando editar o nome, então a alteração é persistida e refletida no board.
- Dado coluna existente, quando arrastar para reordenar, então a nova ordem é persistida com reflexo visual em ≤ 1,5s.
- Dado nome inválido ou vazio, quando submeter, então a validação impede e mantém o nome anterior.
Regras de negócio: —
Evidência (screenshot):
Deploy: link a definir
RNF01 — Isolamento de acesso administrativo
Classificação: Segurança
Descrição: Toda rota do painel administrativo é servida em endpoint/caminho distinto do site público e exige token de sessão (JWT) válido; requisições sem token válido recebem HTTP 401/403 e nunca renderizam dados administrativos, mesmo parcialmente.
Evidência (screenshot):
Verificação: Resultados V&V da IT2
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
RNF22 — Reorganização intuitiva (colunas do CRM)
Classificação: Usabilidade
Descrição: A reordenação de colunas do funil por arrastar-e-soltar reflete visualmente a nova ordem em até 1,5s após soltar a coluna, sem recarregar a página, com rollback visual para a ordem original em caso de falha ao persistir.
Evidência (screenshot):
Verificação: Resultados V&V da IT2
Definition of Ready — Evidências
Checklist do DoR aplicado à F20 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 #176 — 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 #176 — 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 |
Definition of Done — Evidências
Checklist do DoD verificado ao encerrar a F20. 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 #176 — evidências anexadas na descrição da issue |
| Testes automatizados passando (unitários + integração) | ✅ | Issue #176 — evidências anexadas na descrição da issue |
| Lint sem erros e formatação OK (ESLint + Prettier) | ✅ | Issue #176 — evidências anexadas na descrição da issue |
| CI verde (build + testes + lint) | ✅ | Issue #176 — evidências anexadas na descrição da issue |
| PR aprovado por Chief Programmer ou Project Manager | ✅ | Issue #176 — PR de resolução com approve registrado |
| Migration de banco aplicada | ✅ | Issue #176 — evidências anexadas na descrição da issue |
| Sem vulnerabilidades críticas (SAST/linting de segurança) | ✅ | Issue #176 — 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 #176 — fechada via merge do PR (closes #N) |