Restaura o filtro de situação na listagem de alunos

[msoares94]

Contexto

A listagem de alunos (ieducar/intranet/educar_aluno_lst.php) tinha um filtro "Situação" (situação da matrícula: Cursando, Transferido, Falecido, etc.) que facilitava localizar alunos em situações específicas.

Ele foi removido em 2022: primeiro a busca deixou de usar o INNER JOIN com a view relatorio.view_situacao, passando a filtrar direto em matricula.aprovado (commit e1aab68bd, "Remove view situação e aplica filtro direto na matricula"), e em seguida o campo saiu da tela (commit 0c6dd38e1 / merge 862d72c9c, branch try-fix-student-search). Quando a busca foi reescrita para Eloquent (LegacyStudentBuilder::findStudentWithMultipleSearch), o filtro não foi reintroduzido. Hoje não há como filtrar a listagem de alunos por situação da matrícula.

O que este PR faz

Reintroduz o select "Situação" na seção "Filtros de alunos", já na arquitetura atual (StudentFilter + LegacyStudentBuilder), reusando componentes existentes.

Implementação

• app/Models/DataSearch/StudentFilter.php: novo parâmetro enrollmentStatus.
• ieducar/intranet/educar_aluno_lst.php: re-adiciona inputsHelper()->dynamic('situacaoMatricula') (reusa o helper Portabilis_View_Helper_DynamicInput_SituacaoMatricula e o enum EnrollmentStatusFilter); alimenta enrollmentStatus (vira null quando "Todas"/ALL → no-op).
• app/Models/Builders/LegacyStudentBuilder.php: o filtro registration passa a aceitar status e whereRegistration() filtra por matricula.aprovado via whereHas('registrations', ...), mantendo active():
  • "Exceto Transferidos/Deixou de Frequentar" (id 9) → whereNotIn('aprovado', [RegistrationStatus::TRANSFERRED, RegistrationStatus::ABANDONED]);
  • demais → where('aprovado', $status).

Por que não reintroduz o problema da remoção anterior

A remoção de 2022 estava ligada ao INNER JOIN com relatorio.view_situacao. Esta versão não usa a view: filtra direto em matricula.aprovado via whereHas('registrations', ...) (subconsulta EXISTS), sem multiplicar linhas. É o mesmo caminho que o projeto já adotou no commit e1aab68bd e que os scopes de LegacyRegistrationBuilder (statusTransfer(), finalized()) já usam. A relatorio.view_situacao opera no nível de matrícula_turma (join por cod_matricula/cod_turma/sequencial), inadequada para uma listagem por aluno.

Como testar

1. Acesse a listagem de alunos (menu Alunos).
2. Em "Filtros de alunos", selecione uma Situação (ex.: Transferido) e busque.
3. Confira os resultados, situações como Transferido/Falecido (cujas matrículas permanecem ativo = 1) aparecem; "Todas" não aplica filtro; "Exceto Transferidos/Deixou de Frequentar" exclui as situações 4 e 6.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[edersoares]

@edineivaldameri consegue verificar se com as melhorias na view_situacao podemos voltar a fazer o join e com isso retornar este filtro com o comportamento padrão de sempre fazer join com a view?

[edineivaldameri]

@msoares94 as remoções ocorrem por performance e pela confusão que causava em diversos clientes por não se saber exatamente qual matrícula considerar dentro do cadastro do aluno, quando filtros como o ano não eram preenchido por exemplo.

Nesse cenário encaminhei o PR para análise da a área de produto e assim que estivermos um parecer a gente organiza o possível fluxo aqui.

[Fred-A-P]

@edineivaldameri A restauração do filtro é coerente com necessidade dos usuários, e após a mudança de organização nessa seção podemos aninhar novamente o filtro de situação sem reproduzir os problemas de usabilidade antigos, ficaria da seguinte forma:

Deixo com você a avaliação da parte de performance da tela, certificando a melhor implementação respeitando os padrões ideais.

PSC @betinaribeiro