Inscrição online em disciplinas

[JoaoFelipe]

Esta issue depende da #346

O objetivo desta issue é permitir que alunos possam se inscrever em disciplinas online no período de inscrição de disciplinas. Essa inscrição não será efetivada imediatamente. Após a inscrição feita por alunos, orientadores deverão confirmar a inscrição.

Para esta issue serão necessárias algumas sub-tarefas: 1- Configuração no sistema de qual é o período de inscrição online. A interface do aluno só deve exibir o formulário de inscrição no período exibido. 2- Cadastro das disciplinas na interface do aluno. Dúvidas: Que validações devem ser feitas? Penso só em impedir pegar disciplina repetida (mas estou em dúvida nisso por conta de estágio em docência) e impedir pegar disciplina com horário conflitante. 3- Página na interface de controle do SAPOS para orientadores confirmarem a inscrição. A princípio, penso em criar uma página genérica de "Pendências" que vai servir tanto para a validação de inscrições em disciplinas quanto para validar pedidos de bancas. Dúvidas: Quando alguma pendência for registrada, devemos notificar todos os envolvidos de forma hardcoded no sistema? Ou é melhor deixar em uma notificação configurável? Apenas orientadores podem validar inscrições? Como fica a inscrição no mestrado para quem ainda não tem orientador?

[braganholo]

Quanto à sua dúvida no item 2: Acho que as validações que podem ser feitas de forma automática são só essas mesmo. A questão da disciplina repetida nós podemos controlar pelo TIPO de disciplina. Toda disciplina é ligada a um tipo, e no cadastro de tipo existe um booleano que diz se pode haver inscrição repetida nas disciplinas daquele tipo ou não. Exemplos: Pesquisa de Dissertação/Tese, Estágio Em Docência e Tópicos Avançados (essa última é pq às vezes a disciplina é oferecida com ementas diferentes, mas usando o mesmo código).

Temos que pensar em como tratar as inscrições de alunos avulsos -- acho que essas continuariam sendo feitas via secretaria, certo @leomurta ?

Quanto à sua dúvida no item 3: acho que fazer com que as notificações sejam configuráveis seria melhor, já pensando que o SAPOS está sendo usado em programas de pós com regras diferentes.

Aqui para @leomurta discutir com Plastino: Acho que se o orientador não validar dentro de X tempo, a coordenação deveria validar. Os alunos que não possuem orientador deveriam ter a matrícula validada pelo coordenador? Ou vamos passar a ter um conceito de orientador de área que ficaria responsável por isso? Nos programas de pós que não tiverem esse conceito, bastaria cadastrar o coordenador como coordenador de todas as áreas de pesquisa.

Entendo que a gente vai precisar de algo como um workflow pra isso e para as validações de pedidos de banca e prorrogação.

[nataliacfUFF]

Oi pessoal,

Acaba que precisa ter uma validação do orientador e uma da coordenação/secretaria. A coordenação vê se o aluno ainda pode se inscrever (por exemplo, se já não deu causa para desligamento por reprovação) e o orientador vê a questão acadêmica.

Há ainda a questão de exceder o número de vagas na turma, que poderia ser resolvido pela coordenação ou pelo sapos (se isso for simples de implementar...não sei se todos os programas seguem as regras da UFF...talvez seja mais fácil mesmo deixar a coordenação decidir).

Com relação aos avulsos, acho que deveria ser realmente via secretaria, mas seria legal poder cadastrar no sapos para que a informação não se perca no futuro. Os alunos regulares e os especiais deveriam poder se inscrever diretamente pelo sistema.

[leomurta]

Concordo que avulso deveria continuar pela secretaria, até pq eles não terão acesso ao sistema, como discutirmos na issue #346.

Será que não podemos separar o que é validação do que é efetivação para simplificar? A validação seria o ok do orientador ou do coordenador (do programa ou de área) sob o aspecto técnico. Se o orientador não concorda, avisa ao aluno e ele edita até ficar ok. Aí, todos os pedidos (validados ou não) ficariam disponíveis numa tela para a secretaria efetivar (ou não). A efetivação mudaria o estado daquela inscrição de "solicitada" para "ativa" ou algo assim. As que não fossem efetivadas seriam resolvidas entre a secretaria e o aluno. O que acham?

Quanto ao item 1 do João, Já temos Turmas no Sapos, e elas têm ano/período. Acho que poderíamos ter uma entidade que representasse o quadro de horários e ela teria ano/período assim como uma coleção de turmas. Nela seria possível configurar a data limite de inscrição, assim como a regra de validação (orientador, chefe de área, coordenador).

Achei interessante todo usuário ter uma página de pendências. Na verdade, poderia ser a landing page do Sapos. Isso seria útil não só para esse workflow de inscrição, mas para outros também. No caso do aluno, poderia ser a página que a @nataliacfUFF sugeriu na issue #346 que listasse todas as etapas e prorrogações e indicasse o que já foi feito. No caso do professor, poderia, além de mostrar ações pendentes, dar um overview das pendências dos seus alunos. Mas isso poderia ir para uma issue seguinte, para conseguirmos fechar as inscrições online rapidamente.

@nataliacfUFF , essa questão de limite do número de alunos em turmas não é tratada pelo Sapos hoje. Acho que nós não temos essa demanda na computação, já que não limitamos. Mas se vcs tiverem essa necessidade, podemos criar uma issue própria para isso. O processo pode ser mais complexo, pois podemos querer usar diferentes critérios para priorizar (CR, ano de ingresso, nível, FIFO, etc.). Seja como for, deixaria de fora dessa issue para não elevarmos muito a complexidade e termos uma versão em produção o quanto antes.

Por fim, sobre termos avulsos geridos no sistema, é uma decisão de uso. Hoje já fazemos isso na computação.

[nataliacfUFF]

Então, o limite de alunos não é uma issue urgente... Já aconteceu algumas vezes no programa com algumas matérias, mas sempre resolvemos olhando na mão quem deveria sair. Com o painel de validação da secretaria, já daria para fazer isso indicando ao aluno que ele foi excluído por falta de vagas.

Com relação aos alunos, acho que a questão talvez fosse associar um atributo para o tipo de aluno (regular, especial ou avulso) e usar essas tags para decidir o que cada um pode fazer. No nosso caso, o especial é bem parecido com o regular e o avulso é o cara que realmente não faz parte do programa e não deveria ter acesso ao sistema.

Em seg, 26 de jul de 2021 18:06, Leonardo Gresta Paulino Murta < @.***> escreveu:

Concordo que avulso deveria continuar pela secretaria, até pq eles não terão acesso ao sistema, como discutirmos na issue #346 https://github.com/gems-uff/sapos/issues/346.

Será que não podemos separar o que é validação do que é efetivação para simplificar? A validação seria o ok do orientador ou do coordenador (do programa ou de área) sob o aspecto técnico. Se o orientador não concorda, avisa ao aluno e ele edita até ficar ok. Aí, todos os pedidos (validados ou não) ficariam disponíveis numa tela para a secretaria efetivar (ou não). A efetivação mudaria o estado daquela inscrição de "solicitada" para "ativa" ou algo assim. As que não fossem efetivadas seriam resolvidas entre a secretaria e o aluno. O que acham?

Quanto ao item 1 do João, Já temos Turmas no Sapos, e elas têm ano/período. Acho que poderíamos ter uma entidade que representasse o quadro de horários e ela teria ano/período assim como uma coleção de turmas. Nela seria possível configurar a data limite de inscrição, assim como a regra de validação (orientador, chefe de área, coordenador).

Achei interessante todo usuário ter uma página de pendências. Na verdade, poderia ser a landing page do Sapos. Isso seria útil não só para esse workflow de inscrição, mas para outros também. No caso do aluno, poderia ser a página que a @nataliacfUFF https://github.com/nataliacfUFF sugeriu na issue #346 https://github.com/gems-uff/sapos/issues/346 que listasse todas as etapas e prorrogações e indicasse o que já foi feito. No caso do professor, poderia, além de mostrar ações pendentes, dar um overview das pendências dos seus alunos. Mas isso poderia ir para uma issue seguinte, para conseguirmos fechar as inscrições online rapidamente.

@nataliacfUFF https://github.com/nataliacfUFF , essa questão de limite do número de alunos em turmas não é tratada pelo Sapos hoje. Acho que nós não temos essa demanda na computação, já que não limitamos. Mas se vcs tiverem essa necessidade, podemos criar uma issue própria para isso. O processo pode ser mais complexo, pois podemos querer usar diferentes critérios para priorizar (CR, ano de ingresso, nível, FIFO, etc.). Seja como for, deixaria de fora dessa issue para não elevarmos muito a complexidade e termos uma versão em produção o quanto antes.

Por fim, sobre termos avulsos geridos no sistema, é uma decisão de uso. Hoje já fazemos isso na computação.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/347#issuecomment-887026096, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJFP5YAOTCUR5776QETTZXE3RANCNFSM5A52WI7Q .

[Kohwalter]

Mas pq avulsos não poderiam usar o sistema também (para consulta)? Eles poderiam ser User do tipo Avulso, que é Student com restrições na plataforma (read-only em algumas funcionalidades e permitir ele mesmo atualizar seus dados como endereço, telefone, etc).

Na verdade até a inscrição dos avulsos (uma vez que tenham acesso ao SAPOS pelo modelo acima) poderia ser pelo SAPOS, visto que precisará passar pela aprovação da Secretaria de qualquer forma...

Acho válido necessitar do ok do orientador (ou coordenador caso não tenha, visto que ele é instancia superior de coordenador: isso na verdade poderia ser uma hierarquia: orientador > coordenador de área > coordenador da pós) e depois da secretaria.

Para o orientador provavelmente seria um OK e NOK (com um campo de justificativa para não precisar ter troca de e-mail externa?) e a secretaria seria OK e NOK (com justificava para o NOK. Ex: Rejeitado por causa de Turma cheia).

A página de pendencias para o aluno é bem interessante.

[leomurta]

@nataliacfUFF , em matrícula já temos um campo "tipo de matrícula". Nela, aqui na computação, usamos os valores "regular", "especial", "avulso" e "trancada". Isso fica em matrícula pois o mesmo aluno pode ter várias matrículas (mestrado, doutorado, etc.). Aqui, qq aluno avulso é cadastrado no Sapos com o tipo de matrícula configurado como "avulso". A configuração do que um "tipo de matrícula" pode fazer poderia ser feita na entidade que representa o tipo de matrícula, que é configurável: https://github.com/gems-uff/sapos/blob/master/app/models/enrollment_status.rb

@Kohwalter , os avulsos não têm nenhum vínculo com a pós. Acho que dar acesso a um sistema pode dar margem para algum aluno entrar na justiça argumentando que é regular. Eu deixaria de fora nesse momento. A única declaração que eles têm direito é a de que cursaram uma determinada disciplina. Podemos até gerar pelo Sapos, mas acho que a secretaria é quem deveria pegar no Sapos e entregar ao aluno. Note que até a inscrição deles é diferente aqui no PGC: tanto o coordenador quanto o professor da disciplina podem ou não concordar.

Lendo o comentário do @Kohwalter me dei conta que a aprovação tem que ser individual para cada inscrição e não para o todo de uma vez. Ou seja, se o aluno está se inscrevendo em 3 turmas, pode ocorrer de 1 ser NOK e outras duas ser OK. @JoaoFelipe , avalie se não vale a pena, para todas as features, fazer um protótipo de tela antes de cair na implementação. Poderíamos inclusive validar com a secretaria, se for o caso. Esse protótipo poderia ser low tech (folha de papel), usando alguma ferramenta de mock de tela ou mesmo já usando a tecnologia final em HTML. Nada aqui é obrigatório, mas pense nisso e veja se não será útil para validar. Ou, se vc achar simples ajustar depois, siga em frente sem o mock.

[braganholo]

Acho que eu entendi o que a Natália quis dizer -- nós podemos adicionar um atributo no tipo de aluno, para configurar lá se ele pode ou não acessar o sistema. Aí cada programa decide se quer ou não permitir acesso para um determinado tipo de aluno. Só tem um detalhe, o tipo na verdade não está associado a Student, mas sim a Enrollment. Então a gente tem que ver como tratar os casos de alunos que possuem várias matrículas (avulso depois mestrado depois doutorado, por exemplo). Imagino que deva valer a matrícula atual do aluno (ou será que permitimos que ele veja as matrículas antigas também?).

[Kohwalter]

@braganholo , no iduff eu consigo acessar todas as minhas matriculas, então acho que poderia ser interessante fazer o mesmo no SAPOS.

[nataliacfUFF]

Acho legal poder ver todas as matrículas, pois, às vezes, é necessário pegar o histórico do curso anterior.

A ideia que tinha falado do atributo é nesse sentido que a Vanessa colocou...seria para ajudar no controle de acesso mesmo.

Em ter, 27 de jul de 2021 13:43, Kohwalter @.***> escreveu:

@braganholo https://github.com/braganholo , no iduff eu consigo acessar todas as minhas matriculas, então acho que poderia ser interessante fazer o mesmo no SAPOS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/347#issuecomment-887666852, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJAIE53ABKIWUYN6ECLTZ3O4DANCNFSM5A52WI7Q .

[JoaoFelipe]

Seguindo sugestão de protótipo e os comentários que foram feitos, essa issue ficaria assim.

1. Inicialmente é cadastrado um quadro de horários com configuração de início e fim de matrícula:

A princípio pensei nesse quadro de horário sendo independente do Turma. Ou seja, continuar permitindo a criação de turma mesmo que o quadro de horário não exista.

A parte de definição de regra de validação (orientador, chefe da área, coordenador) também seria nessa parte, mas consegui pensar em como seria essa configuração. Alguma sugestão?

2. Se estiver no período de inscrição, o link para inscrição aparecerá na página do aluno (issue #353) e o aluno poderá se inscrever marcando as opções desejadas.

3. Ao terminar a inscrição, seria feita uma Solicitação de Inscrição que entraria em uma página de Pendências do Orientador e/ou Coordenador

4. Ao visualizar a solicitação, o responsável teria que marcar cada disciplina como válida ou inválida e teria um campo de texto para comentar.

Se alguma disciplina não fosse marcada, a pendência continuaria lá.

5. Tendo alguma disciplina inválida, o formulário de inscrição apareceria para o aluno com o comentário do responsável e uma marcação de disciplinas inválidas. Alterações entrariam na lista de pendências.

Dúvidas: Será que vale manter o histórico de solicitações/comentários de forma a permitir a consulta por orientadores/alunos? O aluno pode comentar algo de volta?

Até então, esse processo ocorre apenas durante o período de inscrição e orientadores/coordenadores só podem aprovar nesse período.

6. Após o período de inscrição a secretaria deve fazer o processo de efetivação, usando o mesmo formulário do item 4, mas vendo se a disciplina foi aprovada ou não (não sei o quão relevante é). Dúvida: Será que o processo da secretaria de efetivação pode ocorrer em paralelo durante o período de inscrição? No caso, marcariam disciplinas para efetivação, mas elas só seriam efetivadas de fato após o período de inscrição. E qualquer alteração na inscrição teria que ser validada outra vez.

[nataliacfUFF]

Oi João,

Acho que a parte da coordenação e da secretaria são a mesma. Acho que essa parte deveria ser após o período de inscrição e o aluno entra na turma após o ok da coordenação /secretaria (sugiro ter um accept all pra facilitar, caso tudo esteja correto). O ok do orientador deveria ser antes do ok da secretaria/coordenação e poderia correr junto com o período de inscrição.

Acho legal a página de pendências para o orientador dar o ok... Também deveria ter a da coordenação. Ambas deveriam ter a opção de filtragem por aluno.

Em ter, 27 de jul de 2021 19:32, João Felipe N. Pimentel < @.***> escreveu:

Seguindo sugestão de protótipo e os comentários que foram feitos, essa issue ficaria assim.

1. Inicialmente é cadastrado um quadro de horários com configuração de início e fim de matrícula: [image: image] https://user-images.githubusercontent.com/327789/127223285-d20a4adc-3a5a-4100-af21-957b3f333eca.png

A princípio pensei nesse quadro de horário sendo independente do Turma. Ou seja, continuar permitindo a criação de turma mesmo que o quadro de horário não exista.

A parte de definição de regra de validação (orientador, chefe da área, coordenador) também seria nessa parte, mas consegui pensar em como seria essa configuração. Alguma sugestão?

1.

Se estiver no período de inscrição, o link para inscrição aparecerá na página do aluno (issue #353 https://github.com/gems-uff/sapos/issues/353) e o aluno poderá se inscrever marcando as opções desejadas. [image: image] https://user-images.githubusercontent.com/327789/127224549-dafea3f6-1026-416e-a575-1c47c5e51c84.png 2.

Ao terminar a inscrição, seria feita uma Solicitação de Inscrição que entraria em uma página de Pendências do Orientador e/ou Coordenador

[image: image] https://user-images.githubusercontent.com/327789/127230876-677b93f3-9e0e-4077-b190-bb09efdf2125.png

1. Ao visualizar a solicitação, o responsável teria que marcar cada disciplina como válida ou inválida e teria um campo de texto para comentar.

[image: image] https://user-images.githubusercontent.com/327789/127232607-b2cd16d8-9398-4b0a-b2de-9562f1856ac3.png

Se alguma disciplina não fosse marcada, a pendência continuaria lá.

1. Tendo alguma disciplina inválida, o formulário de inscrição apareceria para o aluno com o comentário do responsável e uma marcação de disciplinas inválidas. Alterações entrariam na lista de pendências.

[image: image] https://user-images.githubusercontent.com/327789/127232482-1c317e57-6a4b-46fa-8c97-ec97e76c3aef.png

Dúvidas: Será que vale manter o histórico de solicitações/comentários de forma a permitir a consulta por orientadores/alunos? O aluno pode comentar algo de volta?

Até então, esse processo ocorre apenas durante o período de inscrição e orientadores/coordenadores só podem aprovar nesse período.

1. Após o período de inscrição a secretaria deve fazer o processo de efetivação, usando o mesmo formulário do item 4, mas vendo se a disciplina foi aprovada ou não (não sei o quão relevante é). Dúvida: Será que o processo da secretaria de efetivação pode ocorrer em paralelo durante o período de inscrição? No caso, marcariam disciplinas para efetivação, mas elas só seriam efetivadas de fato após o período de inscrição. E qualquer alteração na inscrição teria que ser validada outra vez.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/347#issuecomment-887877636, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJC72SIWH3KLZPII3V3TZ4XYTANCNFSM5A52WI7Q .

[JoaoFelipe]

O "accept all" que pensei é aquele "Marcar todas" da figura 4. Você pensou em algo diferente?

Essa filtragem por aluno seria uma busca, certo? Pensando nisso, acho que deveria ter 2 buscas

• uma em pendência usando os campos que estão lá (pendência e tipo). O nome do aluno apareceria no campo "pendência".
• e a outra seria a busca normal que existe em matrícula, mas poderia ter uma ação em cada matrícula para mostrar quais são as pendências associadas

Mas talvez seja melhor jogar essa parte de busca para uma issue separada...

[nataliacfUFF]

Seria esse sim!

Eu pensei na filtragem por aluno, pois se tiver algo errado com ele, vai precisar ver a inscrição dele em bloco, para ver tudo o que foi pedido.

Em ter., 27 de jul. de 2021 às 19:52, João Felipe N. Pimentel < @.***> escreveu:

O "accept all" que pensei é aquele "Marcar todas" da figura 4. Você pensou em algo diferente?

Essa filtragem por aluno seria uma busca, certo? Pensando nisso, acho que deveria ter 2 buscas

• uma em pendência usando os campos que estão lá (pendência e tipo). O nome do aluno apareceria no campo "pendência".
• e a outra seria a busca normal que existe em matrícula, mas poderia ter uma ação em cada matrícula para mostrar quais são as pendências associadas

Mas talvez seja melhor jogar essa parte de busca para uma issue separada...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/347#issuecomment-887885292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJC754EPP6UI6UFHXF3TZ42BJANCNFSM5A52WI7Q .

[nataliacfUFF]

Seria também importante filtrar os que o orientador não autorizou ou simplesmente não teve nenhuma ação.

Em ter., 27 de jul. de 2021 às 19:55, Natalia Castro Fernandes < @.***> escreveu:

Seria esse sim!

Eu pensei na filtragem por aluno, pois se tiver algo errado com ele, vai precisar ver a inscrição dele em bloco, para ver tudo o que foi pedido.

Em ter., 27 de jul. de 2021 às 19:52, João Felipe N. Pimentel < @.***> escreveu:

O "accept all" que pensei é aquele "Marcar todas" da figura 4. Você pensou em algo diferente?

Essa filtragem por aluno seria uma busca, certo? Pensando nisso, acho que deveria ter 2 buscas

• uma em pendência usando os campos que estão lá (pendência e tipo). O nome do aluno apareceria no campo "pendência".
• e a outra seria a busca normal que existe em matrícula, mas poderia ter uma ação em cada matrícula para mostrar quais são as pendências associadas

Mas talvez seja melhor jogar essa parte de busca para uma issue separada...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/347#issuecomment-887885292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJC754EPP6UI6UFHXF3TZ42BJANCNFSM5A52WI7Q .

[braganholo]

Sobre essa dúvida: "A parte de definição de regra de validação (orientador, chefe da área, coordenador) também seria nessa parte, mas consegui pensar em como seria essa configuração. Alguma sugestão?"

Daria para ter uma configuração onde o admin poderia configurar a ordem das validações, se precisa aguardar o fim do período de inscrição ou se pode ser em paralelo, etc. Por exemplo, o admin poderia querer configurar que a ordem seja orientador, depois coordenador ou secretaria. E haveria a opção de marcar que a validação do orientador pode ocorrer em paralelo com as inscrições, mas o da secretaria/coordenador não. Um admin de outro programa de pós poderia escolher não envolver o orientador, e usar apenas secretaria, e permitir que fosse em paralelo com as inscrições. Já um admin de um terceiro programa de pós poderia escolher que a validação vai primeiro para o orientador e depois para o coordenador de área, mas não vai para secretaria nem coordenador do curso, e que o ok do orientador e do orientador de área devem ocorrer apenas APÓS o período de inscrição terminar.

[leomurta]

Quanto a esse último comentário da @braganholo , vou sugerir umas simplificações aqui:

1. Não existe paper de "coordenador de área" no Sapos nesse momento, então sugiro deixarmos de fora por agora. Depois podemos fazer uma issue só para incluir esse papel com suas permissões.
2. Seguindo a sugestão da @nataliacfUFF , podemos num primeiro momento deixar coordenação/secretaria como a mesma coisa. No nosso caso, não é. A coordenação faz o papel do orientador para o aluno de mestrado que ainda não tem orientador. Já a secretaria faz verificações mais operacionais, sem julgar o conteúdo das matérias que o aluno está se inscrevendo.
3. Coordenador/secretaria deveriam poder atuar a qualquer momento, sem ter que ficar presos a datas ou ao workflow. Um professor que está viajando pode pedir para a secretaria agir no seu lugar. Se a secretaria vê que tem algo errado, ela poderia barrar desde o início. Sendo assim, manteria ambos (secretaria/coordenador) com permissão total sobre todos os pedidos de inscrição a qualquer momento.
4. Se tudo que eu falei antes estiver ok para vocês, só restou o orientador. Para simplificar, nem criaria configuração para isso. Assumiria que ao fazer uma inscrição, enviamos um e-mail para o aluno e para o orientador, indicando as disciplina (algo parecido com o que já é feito hoje no lançamento de notas). Aí o orientador pode, a qualquer momento, ir lá e indicar se ele está de acordo com cada inscrição ou não, e colocar um comentário se quiser. Isso dispara um e-mail para o aluno e orientador. Se o aluno alterar a inscrição, novamente há e-mail para aluno e orientador, e o ciclo pode reiniciar. Nem preocuparia em ter vários campos de texto. Deixaria dois de "observações": um que o aluno pode preencher desde a primeira solicitação de inscrição e outro que o orientador pode preencher.
5. Notem que se um programa não quer validação de inscrição por parte do orientador, ou se um orientador não quer/pode fazer a validação, não tem problema nenhum. O estado de cada inscrição ficaria "solicitado" (em contraponto a "validada pelo orientador" ou "invalidada pelo orientador") e a coordenação/secretaria tomaria a decisão de aceitar ou não aquela inscrição.

O que acham? Assim talvez tenhamos uma implementação mais simples num primeiro momento e conseguiremos colocar em produção nosso MVP o quanto antes. Depois, se for necessário, podemos ter uma issue para elaborar mais o processo.

[leomurta]

@JoaoFelipe relendo sua mensagem: se for simples manter o histórico de comentários, talvez seja melhor do que o que eu sugeri de dois campos no comentário acima. Assim, em toda interação, qq pessoa pode preencher um campo de comentário antes de salvar. No final das contas, esses comentários seriam sempre listados, junto com a data e o autor. Parece legal.

No mais, para deixar claro, não penso em campos separados de OK para orientador, coordenação, secretaria. Penso em estados de uma inscrição. Ela pode estar no estado "solicitada", "válida" ou "inválida". A mudança de "solicitada" para "válida" (ou "inválida") pode ser feita pelo orientador dentro do prazo ou pela secretaria/coordenação a qq momento. Um processo separado desse é o de efetivação da inscrição, que só pode ser feito pela secretaria/coordenação. Depois do prazo, o coordenador ou a secretaria poderia fazer a efetivação individualmente (clicando "efetivar" em cada inscrição) ou em lote. No caso da efetivação em lote, seguindo a sugestão da @nataliacfUFF , poderíamos ter algumas variações: "efetivar todas válidas" ou "efetivar todas não inválidas", onde a segunda inclui as "solicitada" que não foram validadas. Não sei se um "efetivar todas" no geral faria sentido, pois acabaria efetivando inclusive as inválidas. Ao final desse processo de efetivação, a inscrição passaria para o estado de "efetivada". Note que, do ponto de vista de migração, todas as inscrições existentes hoje deveriam ter nesse novo campo "estado" o valor "efetivada".

[JoaoFelipe]

Aparentemente terminei! O processo é o seguinte:

1- A coordenação/secretaria/admin cria um quadro de horários para o período desejado com uma configuração da data de início e fim das inscrições:

Bonus: além da possibilidade antiga de gerar quadro de horários fazendo busca na tela de turma, há uma ação no quadro de horários que também gera um PDF para o período específico:

2- Durante o período de inscrição, aparece uma opção na página de alunos:

3- Ao entrar nessa opção, são exibidas todas as turmas cadastradas no período (usando a mesma regra de aparecer no quadro de horários). Os alunos podem escolher as disciplinas e enviar uma mensagem.

4- Ao enviar o sistema valida as seleções verificando se tem conflito de horário ou se a disciplina foi cursada anteriormente e exibe os erros

5- Ao corrigir os erros e enviar novamente, o pedido é salvo e tanto orientador quanto aluno recebem notificações por email. Além disso, o link continua visível na página do aluno para editar a inscrição.

6a- Ao logar com um usuário de professor, é possível ver os pedidos de inscrição de seus orientandos na página de pendências:

Um pedido de inscrição fica pendente até que todas as disciplinas do pedido sejam marcadas individualmente como "válida" ou "inválida" (ou "efetivada", mas não dá para marcar diretamente).

6b- Ao logar com um usuário de "coordenacao" ou "secretaria", é possível ver todos os pedidos de inscrição na página de pendências. Além disso, é possível ver necessidades de efetivação para cada disciplina na mesma página de pendência.

Essa parte de efetivação exibe apenas disciplinas marcadas como "válida" ou "solicitada". Se alguma disciplina for marcada como "inválida" pelo professor (ou mesmo por outra pessoa da coordenação/secretaria), ela não vai aparecer na lista.

6c- Além de aparecer na página de pendências, ambas tabelas aparecem no menu de disciplinas:

Nesse menu, as tabelas aparecem completas, sem nenhum filtro. Ou seja, pendencias resolvidas aparecem também.

7- Para validar/invalidar um pedido de inscrição, é possível usar a seguinte ação:

8- Essa ação abre o seguinte form com opções de validação:

9- Ao validar disciplinas, o aluno recebe outro email indicando que a situação do pedido de inscrição foi alterada. Na página do aluno a parte com o link de inscrição muda para:

10- Ao abrir o pedido de inscrição, cores marcam cada situação:

11- Depois do período de inscrição, chega o momento da secretaria/coordenação efetivar pedidos. Essa efetivação pode ser feita de duas formas:

11a- Individualmente para cada disciplina usando a seguinte ação:

11b- Em conjunto usando a ação efetivar que aparece no topo

12- Essa ação efetivar do topo está sujeita às condições de busca do Efetivar Inscrição:

Atenção: Se a busca for feita na página de pendências, só vai achar pedidos marcados como "Válido" ou "Solicitado", mesmo que a condição de busca seja definida como "Inválido". É recomendado que isso seja feito na página de "Efetivar Inscrições" que aparece em disciplinas.

13- A cada disciplina efetivada, o aluno recebe um email indicando que a inscrição foi realizada.

14- Se ainda estiver no período de inscrição, o aluno deixa de poder remover inscrições efetivadas:

Nesse exemplo, é possível alterar as últimas quatro disciplinas à vontade, mas não dá para desmarcar "Estudo Orientado".

---

O que ficou faltando que poderia ir para uma issue futura se vocês quiserem:

• Configurar envolvidos no processo (Quem pode validar? Quem pode efetivar? Quem recebe emails de notificação? Quem fica com pendências na página inicial?)
• Validar tamanho da turma

---

Detalhe de implementação:

Ao invés de usar a entidade class_enrollment para os pedidos de inscrição em disciplinas com um campo novo para indicar se foi efetivada ou não (como tinha sido sugerido), criei uma entidade nova para isso (class_enrollment_request). O motivo foi não ter que tratar efetivação no resto do sistema (boletim, histórico, consultas complexas existentes, etc). Da forma que fiz, o pedido de inscrição só se torna inscrição após a efetivação.