Pular para conteúdo

US1.7

Painel Administrativo para Moderação de Organizações (RF06)

História de Usuário

Como administrador (Sysmin), quero ter um painel para moderar cadastros de organizações sociais para garantir a legitimidade das organizações na plataforma.


Rastreabilidade

Item Código / Referência
User Story US1.7
Requisito Funcional RF06 — Moderar organização: Permitir a validação e aprovação administrativa dos cadastros de organizações.
Característica de Produto CP01 — Gestão de Usuários e Entidades
Requisitos Não-Funcionais RNF04 — Interface responsiva (iOS e Android)
Release Planejada R1 — Fundação (26/05/2026)

Descrição

O Liaison conecta estudantes a organizações do terceiro setor. Para manter a qualidade e a confiabilidade da plataforma, toda organização que se cadastra deve passar por um processo de moderação antes de publicar vagas de voluntariado. O administrador (Sysmin) precisa de uma interface centralizada que permita visualizar os cadastros pendentes, avaliar as informações fornecidas e tomar uma decisão — aprovando, reprovando ou solicitando dados complementares. Cada ação administrativa deve ser registrada para fins de auditoria, e o resultado da moderação deve ser comunicado à organização.

Alcance: Full-stack — painel administrativo no frontend (React Native/Expo), API de moderação no backend (Django REST Framework), e atualização da situação cadastral no banco (PostgreSQL).


Critérios de Aceite (BDD / Gherkin)

Cenário 1: Visualização de organizações pendentes

Dado que o administrador está autenticado como Sysmin Quando ele acessa o painel administrativo de moderação Então o sistema exibe a lista de todas as organizações com cadastro pendente, apresentando nome, CNPJ, responsável e data de cadastro

Cenário 2: Aprovação de organização

Dado que o administrador visualiza os detalhes de uma organização com cadastro pendente Quando ele confirma a ação de aprovação Então o sistema registra a organização como aprovada, libera seu acesso à plataforma, registra a decisão no histórico de auditoria e comunica a aprovação à organização

Cenário 3: Reprovação de organização

Dado que o administrador visualiza os detalhes de uma organização com cadastro pendente Quando ele registra o motivo da reprovação e confirma a ação Então o sistema registra a organização como reprovada, mantém seu acesso bloqueado, registra a decisão e o motivo no histórico de auditoria e comunica a reprovação à organização

Cenário 4: Solicitação de informações complementares

Dado que o administrador visualiza os detalhes de uma organização com cadastro pendente Quando ele descreve quais informações estão faltando e confirma a solicitação Então o sistema mantém o cadastro como pendente, registra a solicitação no histórico de auditoria e comunica à organização quais dados precisam ser complementados

Cenário 5: Filtros e busca no painel

Dado que existem múltiplas organizações em diferentes situações cadastrais (pendente, aprovada, reprovada) Quando o administrador utiliza filtros por nome, CNPJ ou situação Então o sistema exibe apenas as organizações que correspondem aos critérios informados

Cenário 6: Acesso restrito ao perfil Sysmin

Dado que um usuário autenticado como estudante ou organização tenta acessar o painel de moderação Quando ele realiza a requisição Então o sistema nega o acesso por falta de permissão

Regra DoR-G02: Todo item de backlog deve conter pelo menos um cenário de aceitação estruturado no formato Dado / Quando / Então.


Regras de Negócio

  • Exclusividade do Sysmin: Somente o administrador do sistema (Sysmin) está autorizado a avaliar e decidir sobre cadastros de organizações sociais. Nenhum outro perfil de usuário possui essa prerrogativa.
  • Bloqueio de organizações não moderadas: Organizações cujo cadastro ainda não foi aprovado não podem publicar vagas de voluntariado nem aparecer em listagens públicas da plataforma. Esse bloqueio deve ser garantido tanto na interface quanto nas regras de acesso do sistema.
  • Aprovação de cadastro: Uma vez aprovada, a organização está liberada para operar plenamente na plataforma — pode publicar vagas, gerenciar candidaturas e registrar frequência de voluntários.
  • Reprovação de cadastro: Uma vez reprovada, a organização permanece impedida de operar na plataforma. O motivo da reprovação deve ser registrado e comunicado formalmente à organização, permitindo que ela compreenda a decisão e, se aplicável, possa corrigir os dados para uma nova submissão.
  • Solicitação de informações complementares: O administrador pode optar por não aprovar nem reprovar definitivamente, solicitando dados adicionais à organização. Nesse caso, o cadastro permanece pendente até que as informações sejam complementadas.
  • Registro de auditoria: Toda decisão administrativa — aprovação, reprovação ou solicitação de informações — deve ser registrada em histórico de auditoria contendo: identificação do administrador responsável, tipo de ação executada, organização afetada, data e horário, e justificativa ou observações pertinentes.
  • Validade do CNPJ: O CNPJ informado pela organização deve possuir formato válido composto por 14 dígitos.
  • Comunicação da decisão: O resultado do processo de moderação deve ser comunicado à organização. Na ausência de serviço de envio de e-mails, a informação deve estar acessível na própria conta da organização ao realizar login.

Requisitos Técnicos

  • Backend: Endpoint GET /api/v1/admin/organizations/ com filtro por situação cadastral e paginação.
  • Backend: Endpoint POST /api/v1/admin/organizations/{id}/approve/ — executar aprovação de organização.
  • Backend: Endpoint POST /api/v1/admin/organizations/{id}/reject/ — executar reprovação, aceitando o motivo no corpo da requisição.
  • Backend: Endpoint POST /api/v1/admin/organizations/{id}/request-info/ — solicitar informações complementares.
  • Backend: Modelo OrganizationProfile com campo status (pending / approved / rejected), conforme modelo de dados do PROJECT_CONTEXT.md §4.
  • Backend: Classe de permissão customizada (IsAdminUser) garantindo que apenas o perfil Sysmin acesse os endpoints de moderação.
  • Backend: Modelo de registro de auditoria (AdminActionLog) com os campos: administrador, ação, organização-alvo, data/hora e detalhes.
  • Backend: Testes unitários e de integração com pytest, cobertura mínima de 80%.
  • Frontend: Painel administrativo em React Native + Expo com interface responsiva (RNF04). Avaliar se o acesso será via web (Expo web) ou área restrita do aplicativo.
  • Frontend: Componentes de listagem com filtros (nome, CNPJ, situação cadastral) e tela de visualização detalhada do cadastro.
  • Frontend: Testes com Jest + React Native Testing Library, cobertura mínima de 70%.

Referências de Design

  • Protótipo Figma (Desktop): https://www.figma.com/design/f6bQuVohTvZLF5WWPEbNob/Liaison?node-id=0-1&p=f&t=lTwljNNcyUQi1AQz-0
  • Protótipo Figma (Mobile): https://www.figma.com/design/f6bQuVohTvZLF5WWPEbNob/Liaison?node-id=0-1&p=f&t=lTwljNNcyUQi1AQz-0
  • Observação: O design visual do painel administrativo ainda não foi criado no Figma. Deve ser projetado antes do início do desenvolvimento frontend, conforme DoR-G06.

Regra DoR-G06: Para tarefas que envolvem frontend, o link do protótipo (Figma) deve estar anexado à tarefa.


Dependências

  • Relacionada a: #13 (US1.2 / RF02 — Cadastro de Organizações) — A moderação pressupõe que organizações possam se cadastrar. Dependência técnica direta: o cadastro de organização precisa existir para ser moderado.
  • Relacionada a: #14 (US1.3 / RF03 — Autenticação de Usuários) — O Sysmin precisa estar autenticado para acessar o painel. Dependência operacional: a interface do painel só é acessível após login.
  • Tipo de dependência: Hard com #13 (conforme backlog §10.2.3 — item #12, prof. 1). Não é possível moderar organizações que ainda não existem no sistema. Com #14, dependência operacional (o painel exige login, mas seu desenvolvimento pode ocorrer em paralelo).
  • Bloqueada por: #13, #14 — Conforme DoR, não mover para "Em Progresso" até que as dependências estejam concluídas.
  • Bloqueia: Nenhuma diretamente.

Notas

  • Prioridade no backlog (§10.2.3): #12 Must Have, ICE=700 (I=10, C=10, E=7), Quick Win, prof. 1. Depende de RF02. RNF04 (responsividade) é o único requisito não funcional vinculado a este RF na documentação oficial.
  • A moderação de organizações é uma regra de negócio crítica: a validação da situação cadastral deve ser aplicada no backend (DRF permissions), não apenas na interface (PROJECT_CONTEXT.md §10).
  • Edge case: tentativa de aprovar organização com CNPJ já aprovado anteriormente — o sistema deve impedir e alertar o administrador.
  • Edge case: grande volume de cadastros pendentes — implementar paginação desde a primeira versão.
  • Notificações às organizações: se o serviço de e-mail não estiver disponível no MVP, a informação da decisão deve ficar acessível na conta da organização ao realizar login.

Definição de Preparado (DoR)

Item de Verificação (Universal) Evidência / Rastreabilidade Situação
A história está bem descrita e com critérios de aceite? Documentada e alinhada com o escopo do MVP. ✔ Sim
Possui protótipos de interface necessários? Interface mapeada e disponível no Figma da equipe. ✔ Sim
A história é independente o suficiente para ser entregue? Cadeia de dependências resolvida (vide Matriz MVP). ✔ Sim
Foi estimada pela equipe? Estimada utilizando o método ICE Score. ✔ Sim

Definição de Pronto (DoD)

Pergunta Fundamental (Universal) Evidência de Implementação Status
O código foi implementado e revisado? Pull Request aprovado e fundido na branch principal. ✔ Sim
Coerente com o protótipo validado? O layout segue os componentes e tokens de design. ✔ Sim
Passou nos testes necessários? Testes (unitários/integração) executados e aprovados. ✔ Sim
A documentação está atualizada? Atualizada no repositório de requisitos. ✔ Sim

Critérios de Aceitação (CA)

  • Lista de pendentes: O administrador acessa o painel e vê todas as organizações com cadastro aguardando aprovação, com nome, CNPJ, responsável e data de cadastro.
  • Aprovação: O administrador aprova uma organização — o acesso dela é liberado, a decisão é registrada no histórico e a organização é comunicada.
  • Reprovação: O administrador registra o motivo da reprovação e confirma — o acesso permanece bloqueado, a decisão e o motivo ficam no histórico e a organização é comunicada.
  • Pedido de mais informações: O administrador descreve o que está faltando — o cadastro permanece pendente, a solicitação é registrada e a organização recebe a comunicação.
  • Filtros: O administrador consegue filtrar a lista por nome, CNPJ ou situação (pendente, aprovada, reprovada).
  • Acesso restrito: Estudantes e organizações comuns não conseguem acessar este painel.

Acesso & Evidência

  • Código Homologado: Repositório Principal
  • Status de Conclusão: 100% Entregue (conforme Matriz de Completude).