Inscrição online em disciplinas #347
Comments
|
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. |
|
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. |
|
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. |
|
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
<#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 <#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
<#347 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU6PTJFP5YAOTCUR5776QETTZXE3RANCNFSM5A52WI7Q>
.
|
|
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. |
|
@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. |
|
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?). |
|
@braganholo , no iduff eu consigo acessar todas as minhas matriculas, então acho que poderia ser interessante fazer o mesmo no SAPOS. |
|
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
<#347 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU6PTJAIE53ABKIWUYN6ECLTZ3O4DANCNFSM5A52WI7Q>
.
|
|
Seguindo sugestão de protótipo e os comentários que foram feitos, essa issue ficaria assim.
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?
Se alguma disciplina não fosse marcada, a pendência continuaria lá.
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.
|
|
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
<#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
<#347 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU6PTJC72SIWH3KLZPII3V3TZ4XYTANCNFSM5A52WI7Q>
.
|
|
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
Mas talvez seja melhor jogar essa parte de busca para uma issue separada... |
|
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
<#347 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU6PTJC754EPP6UI6UFHXF3TZ42BJANCNFSM5A52WI7Q>
.
|
|
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
> <#347 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AU6PTJC754EPP6UI6UFHXF3TZ42BJANCNFSM5A52WI7Q>
> .
>
|
|
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. |
|
Quanto a esse último comentário da @braganholo , vou sugerir umas simplificações aqui:
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. |
|
@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". |
…lidations to moments that affect them, create helpers to improve enroll table view
… Add enrollment link to class enrrollment request
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?
The text was updated successfully, but these errors were encountered: