edumanagerpro2/MEMORY.md

5.3 KiB

Log da Migração Massiva SQL-First (Sessão Completa)

Visão Geral

Nesta sessão de trabalho, realizamos o "core" da transição do sistema EduManager, saindo do modelo puramente JSON (school_data.json) e consolidando 4 módulos centrais diretamente no Banco de Dados Relacional PostgreSQL.

Módulos Migrados

Fase 4: Gestão de Alunos e Autenticação

  • Backend Manager: CRUD no database.js para tabela alunos, com rotas /api/alunos e /api/alunos/:id/rematricular no server.selfhosted.js que executam operações no PostgreSQL e realizam sincronização reversa em tempo real no legado school_data.json para total compatibilidade legacy.
  • Frontend Manager (Students.tsx): Completamente refatorado para ler e gravar diretamente nas rotas relacionais /api/alunos, eliminando 100% das chamadas dbService.saveData nesta tela, mantendo apenas o estado em memória sincronizado para continuidade UX.
  • Portal do Aluno: Login (/api/portal/login) e perfil (/api/portal/me) reescritos para consultar a tabela alunos no PostgreSQL.

Fase 5: Avaliações e Provas

  • Backend e Frontend conectados às tabelas provas e questoes_provas.

Fase 6: Cronograma e Aulas

  • Backend Manager: Queries em lote (insertAulas, getAulasByTurma, getAllAulas, deleteAulas).
  • Frontend Manager (LessonSchedule.tsx): Consome fetch('/api/aulas') em estado próprio (dbLessons).
  • Frontend Manager (Classes.tsx): Ao criar/editar turma e gerar cronograma, agora envia aulas via POST /api/aulas/lote para o PostgreSQL.
  • Portal do Aluno: Rota /api/portal/aulas faz SELECT FROM aulas WHERE turma_id = ANY(...).

Fase 7: Contratos e Modelos

  • Backend Manager: CRUD para contratos e modelos_contrato.
  • Frontend Manager (Contracts.tsx): Consome /api/contratos e /api/modelos-contrato.
  • Portal do Aluno: Rota /api/portal/contratos faz SELECT FROM contratos WHERE aluno_id = $1.

Bugs Encontrados e Corrigidos

🐛 Bug 1: Tela Branca na Aba Alunos (Students.tsx)

  • Causa: Referência circular no useStateuseState<any[]>(dbClasses || []) referenciava a si mesma.
  • Fix: Alterado para useState<any[]>(data?.classes || []).

🐛 Bug 2: Dados Não Migrados para PostgreSQL

  • Causa: A rotina syncJsonToRelationalTables só roda quando o Manager salva o JSON via PUT /api/school-data. Como a migração era nova, os dados nunca foram sincronizados.
  • Fix: Criado script migrate_aulas_contratos.cjs que conecta diretamente ao PostgreSQL de produção e roda os INSERTs.
  • Resultado: 109 aulas, 9 contratos, 1 modelo e 89 frequências migrados com sucesso.

🐛 Bug 3: Aulas Órfãs (FK Constraint)

  • Causa: 57 aulas no JSON pertenciam a uma turma deletada (d48b268c-...), causando violação de FK.
  • Fix: O script filtra aulas cujo classId não existe na tabela turmas.

🐛 Bug 4: Contratos Não Apareciam no Manager

  • Causa: A função getContratos() retornava o campo como date, mas o frontend (Contracts.tsx) esperava createdAt.
  • Fix: Corrigido o mapeamento em database.js para retornar createdAt: r.created_at_fmt.

🐛 Bug 5: Classes.tsx Não Salvava Aulas no PostgreSQL

  • Causa: Ao criar/editar turma com cronograma, as aulas geradas eram salvas apenas no JSON (data.lessons), nunca no banco.
  • Fix: Adicionado fetch('/api/aulas/lote') no Classes.tsx para enviar as aulas geradas ao PostgreSQL.

Estado Final do Banco de Dados

Tabela Registros
alunos 9
aulas 109
contratos 9
frequencias 89
modelos_contrato 1
provas 3
turmas 3

Padrões de Arquitetura

  1. Reverse Sync (Mão Dupla): Frontend salva no SQL via API e mantém backup no JSON.
  2. Fallback Gradual: Portal prioriza SQL, invoca JSON apenas se banco retornar vazio.
  3. Migração de Dados: Executada via script Node.js conectando diretamente ao PostgreSQL de produção (host: 150.230.87.131, user: edumanager).

Fase 8: Consolidação de Frequência, Registro de Matrículas e Contratos Relacionais

  • Justificativa Única Rígida (Portal): Implementação de regra de validação rígida impedindo que o aluno envie mais de uma justificativa por aula. O Portal do Aluno agora exibe um aviso dinâmico informando que a aula já possui justificativa e desativa o envio. O backend valida a existência e retorna erro HTTP 400.
  • Sincronização Direta de Contratos (Manager): O fluxo de salvamento de matrículas foi aprimorado para disparar uma chamada de POST /api/contratos em tempo real ao salvar o aluno, escrevendo a emissão do contrato diretamente no PostgreSQL na VPS.
  • Refinamento do Modal de Alunos (Manager): O checkbox "Gerar Taxa" foi inteiramente removido do modal de matrícula. O checkbox "Gerar Contrato Automático" agora vem selecionado (true) por padrão em novos cadastros e desmarcado (false) ao editar matrículas para prevenir duplicações acidentais.
  • Relatório de Frequência Geral em PDF (Manager): Refatoração do exportador de PDF no módulo Registro de Frequência para gerar uma Ficha de Frequência Geral (Roster de todos os alunos ativos da turma, com contagem acumulada de presenças, faltas, justificativas e porcentagem de frequência de cada um) de modo a corresponder perfeitamente ao que o administrador visualiza na modal, eliminando downloads vazios.