search

gems-uff / sapos

SAPOS main goal is to ease the management of information related to graduate programs such as enrollments, courses, advisement, scholarships, requirements, among others.
http://gems-uff.github.io/sapos/
MIT License
28 stars 14 forks source link

Permitir acesso aos alunos #346

Closed JoaoFelipe closed 3 years ago

JoaoFelipe commented 3 years ago

Atualmente o SAPOS está restrito a coordenação, secretaria, professores e suporte. Seria interessante dar acesso a alunos para que possam realizar automaticamente diversas atividades como inscrição em disciplinas, geração de declarações (histórico, regularidade da matrícula), pedido de banca e prorrogação e alteração de cadastro.

Esta issue tratará apenas da permissão de acesso a alunos. Outras issues serão criadas para cada uma dessas atividades.

Na versão atual do SAPOS, temos alunos cadastrados em Student e temos usuários do sistema cadastrados em User. Para esta issue, proponho a criação de uma página de cadastro de User que peça email, CPF, data de nascimento e naturalidade (cidade) e senha para a criação de um User que possa fazer login no sistema.

Ao preencher o cadastro, o sistema deve verificar se as informações cadastradas estão de acordo com as informações cadastradas em Student. Um email de verificação deve ser enviado.

Dúvidas: Será que vale a pena incluir nome também na verificação? Como pode ter variações na escrita (letra maiuscula, acento, nome sem um dos sobrenomes), penso que pode acabar atrapalhando. Algum outro campo deve ser incluido?

Ao fazer o cadastro, o acesso dos alunos deve ser feito a uma página diferente da visão padrão do SAPOS. Alunos não poderão ter acesso a nenhuma funcionalidade de controle.

Para esta issue, a página de aluno deverá apenas exibir suas informações pessoais e permitir trocar a senha de usuário.

braganholo commented 3 years ago

Eu acho que apenas o CPF e data de nascimento devem ser suficientes. Eu nem colocaria naturalidade, pq não é um campo obrigatório no SAPOS. Acho que para alunos avulsos isso não é preenchido (aqui temos que ter cuidado, pq aluno avulso não deveria poder emitir declaração de aluno regularmente matriculado). A data de nascimento tb não é obrigatória -- teríamos que mudar isso e fazer com que fosse obrigatória no cadastro de students no SAPOS.

nataliacfUFF commented 3 years ago

Oi pessoal,

A associação entre user e student não poderia ser automática? Ao contrário dos professores, potencialmente, todos os alunos terão que entrar no sistema. Poderia até, idealmente, ser gerado um e-mail automático de boas-vindas explicando como acessar e como gerar a senha (no estilo id.uff, que pergunta alguns dados do usuário). Digo isso para reduzir o trabalho da secretaria, que já tem que lançar todos os alunos no sistema.

Com relação aos avulsos, especiais e regulares, acho que seria interessante a gente poder marcar isso no sistema. No momento, o avulso não tem matrícula UFF, mas o especial e o regular têm. Mas para o especial, não pode ser gerada a declaração de regularmente matriculado como aluno regular, mas sim como aluno especial.

Sobre o pedido de banca, em alguns programas ele é feito pelo aluno, mas em outros é feito pelo orientador. Acho que esse ponto deveria ser configurável no sistema.

Ainda sobre o painel dos alunos, se não for muito complexo, talvez fosse legal ter algum tipo de visualização que mostrasse o que eles já fizeram e o que falta. A maior parte das dúvidas que a gente recebe (de alunos e professores) são sobre prazo final e se já cumpriu ou não todos os créditos e requisitos. Se isso estivesse disponível para alunos, professores e secretaria, acredito que deixaria a vida de todos mais fácil.

leomurta commented 3 years ago

Seguindo a sugestão da Natália, vou propor aqui um design diferente para vcs avaliarem. Vejo duas situações que precisamos cobrir:

  1. Os alunos atuais que são tuplas de Student: nesse caso, poderíamos fazer uma rotina que cria automaticamente um User usando o e-mail cadastrado em Student, desde que esse seja do tipo Regular (será que todos os programas usam essa mesma classificação de tipos?). Com o user criado, poderíamos disparar o procedimento de troca de senha, que se não me engano acontece quando criamos um User do zero.

  2. Os novos alunos: no momento de criação do aluno, o respectivo user poderia ser criado, caso o aluno seja regular, seguindo a mesma filosofia acima.

Note que esse procedimento número 2 poderia ser pensado também para professor, já que hoje temos que criar na mão o professor, o user e vincular ambos. Só que, assim como Student, o Professor tb precisa ser de um tipo específico (credenciado?) para poder ter acesso ao Sapos. Caso achem arriscado esse procedimento automático de criar User quando o Student/Professor é criado, uma alternativa seria ter um botão em Student/Professor para criar o User, caso ele não existe. Outra alternativa seria uma página de solicitação. Mas acho que não precisaria confirmar dados pessoais, já que o e-mail para cadastrar senha vai para o e-mail cadastrado em Student, então não vejo muita possibilidade de fraude.

Essa discussão de tipo de aluno é válida nessa issue e na issue #348. Acho que no tipo de aluno poderia ter uma flag para indicar se aquele tipo deve ou não ter acesso ao sistema (essa issue). Além disso, lá nas declarações também poderíamos pensar em configurar se aquela declaração é restrita a um tipo específico.

Legal o comentário da @nataliacfUFF sobre indicar quais papéis estão autorizados a fazer quais pedidos. Talvez uma primeira implementação poderia aceitar qq um e depois poderíamos refinar para isso. Mas talvez fosse melhor migrarmos essa discussão para a issue #351.

Essa ideia final da @nataliacfUFF poderia se tornar uma issue por si só. Algo que mostrasse todas as etapas e prorrogações e indicasse o que já foi feito e o que ainda não. Bem legal a ideia. Só precisaríamos depois priorizar essa issue frente às demais.

Kohwalter commented 3 years ago

Também acho legal a ideia de fazer automaticamente dos Students atuais e da forma sugerida por Leo, disparando um e-mail de redefinição de senha. Para novos alunos, essa forma que o Leo sugeriu também me parece ser boa.

A ideia de ter um portal diferente para os alunos é interessante.

Sobre os dados: Geralmente CPF é o suficiente. Acho que nem data de nascimento seja necessário. Porém, e para os alunos que não tem CPF? Ou seja, os estrangeiros? Todos os alunos tem email do iduff? Isso seria interessante para os estrangeiros, onde poderia usar o @iduff em vez do cpf para fazer login.

Pensando no cadastro de professores, já que foi mencionado, será que não poderia ter uma tabela de "credenciamento" que automaticamente seria usada para vincular o User (do professor) a Professor credenciado? Assim, a secretária só precisaria atualizar essa tabela (inserir/remover Users dela) para ajustar os professores credenciados.

Sobre tipos de user, então pelo que entendi, teriamos: Students, Avulso (Loose?), Professor.

leomurta commented 3 years ago

O controle de acesso no Sapos é feito pela lib devise. O username é o e-mail.

Já existe uma entidade que representa o credenciamento (https://github.com/gems-uff/sapos/blob/master/app/models/advisement_authorization.rb). Ela poderia ser usada sim para controle de acesso. Ou seja, só deixar logar um user do tipo professor que esteja credenciado. É isso, @Kohwalter ?

User tem vários outros tipos (Role), que não são mapeados a entidades do Sapos, como, por exemplo, admin, coordenador, secretaria, suporte. Usamos a lib cancancan para definir as permissões de um User em função do seu tipo. Aqui é que configuramos a permissão de cada Role: https://github.com/gems-uff/sapos/blob/master/app/models/ability.rb.

A propósito, @JoaoFelipe , apesar de eu ter gostado de termos uma interface própria para users do tipo Student, pense bem sobre isso. Será que não é mais fácil usar o ActiveScaffold e mostrar só o que eles podem ver/editar. Possivelmente não, mas quis falar isso aqui para vc refletir.

Kohwalter commented 3 years ago

Isso mesmo, @leomurta.

JoaoFelipe commented 3 years ago

Nessa sugestão de associar automaticamente Student a User e disparar emails de recuperação de senha para alunos específicos, fiquei pensando na issue #350 (que acabei de renomear de "evento" para "ação") e na infrastrutura de notificações/consultas complexas.

Que tal algo assim:

  1. Teríamos uma ação de Criar usuário a partir de um email (estudante ou professor). Após associar, o usuário criado ficaria em um estado especial -- Seria necessário fazer a issue #350 pelo menos parcialmente antes.
  2. O programa poderia definir uma consulta para buscar todos os estudantes de um determinado tipo sem usuário (usando o que já existe de consultas complexas) -- Essa consulta teria que ser associada de alguma forma à ação: para cada aluno retornado pela consulta, executar a ação de criação.
  3. Como a ação colocaria o usuário em um estado especial, em seguida poderia ter uma notificação automática do sapos (também configurada pelo programa) buscando todos os usuários nesse estado e mandando um email de boas vindas com um link para recuperar a senha..
  4. Ao seguir o processo de recuperar senha, o usuário sairia desse estado especial.

A consulta do passo 2 também poderia usar o sistema de notificação, mas sem notificação: apenas ser realizada periodicamente para criar a associação automaticamente.

Além disso, com a issue #350 completa, o sistema de ações poderia colocar um botão na interface de alunos e professores para a criação "manual" do usuário quando não satisfizesse a configuração da consulta do passo 2.

leomurta commented 3 years ago

@JoaoFelipe , mas será que não podemos encarar essa situação como uma migração ao invés de uma funcionalidade? Isso só será necessário para os programas que já estão usando o Sapos e só será rodado uma vez, para criar os usuários dos alunos vigentes. Quem começar depois não vai ter aluno para migrar em lote. Falo isso pq acho que seria muito mais simples termos um script para fazer isso do que tudo isso que vc comentou, não?

No mais, acho que esse estado especial já é esperado na gem devise, para usuários recém-criados. Dá uma conferida.

JoaoFelipe commented 3 years ago

Pode ser uma migração sim e realmente seria bem mais fácil de fazer. Talvez só fique mais amarrado na hora de configurar. Em relação ao devise, vi agora que ele tem um campo confirmed_at que começa como nulo e serve para isso.

Então a proposta agora é:

  1. Adicionar um campo em tipos de matrícula (enrollment_statuses) para indicar se matrículas deste tipo devem estar associadas a usuários.
  2. Criar uma migração feita por um comando (rake sapos:alunos-usuarios talvez) que verifique quais alunos desses tipos não possuem usuário associado, crie e mande um email de troca de senha/confirmação. (a alternativa é colocar em uma migration, mas ficaria meio complicado pedir para migrarem para uma versão intermediária, configurar o campo certo e só então ir para a versão mais nova que executa essa migration automática). A dificuldade aqui é mandar o email com o link certo. Existe alguma variável que indica qual é a url do servidor?
  3. Ao criar uma matricula de um dos tipos configurados, de um aluno que ainda não possui usuário, criar automaticamente o usuário e mandas email de troca de senha/confirmação.
braganholo commented 3 years ago

Não temos variável que indique a URL do servidor, mas não sei se o Rails não tem uma forma de extrair isso... pode ser que tenha. @Carlos-Eduardo-Cabral-da-Cunha, você sabe?

JoaoFelipe commented 3 years ago

Se o comando fosse feito pelo site (com a sugestão anterior de ação, por exemplo), isso poderia ser extraído da requisição. O problema é que executando como um comando externo de migração, o comando não tem como saber essa URL. A não ser que passe como argumento, mas acho que seria melhor ter uma variável configurada pra isso.

leomurta commented 3 years ago

@JoaoFelipe , eu hoje rodo scripts no rails com o comando bundle exec rails runner script.rb. Não sei se esse rake sapos:alunos-usuarios daria no mesmo. Não acho que migration (no sentido de migração de BD) seja o caminho, pois o programa pode não querer dar acesso aos usuários. Isso só estaria lá para facilitar a vida de quem quer. Caso contrário, seria necessário criar o usuário e indicar o respectivo aluno para cada aluno.

Mas vendo essa discussão do link, outra alternativa é colocar na aba Configurações/Usuários um botão para criação de usuários em lote. Seria basicamente igual ao script, mas disparado pela interface. Lá poderíamos primeiro listar todos os alunos/professores credenciados que estão sem usuários com uma checkbox do lado e uma opção de select/deselect all. No final, um botão de "criar". O que acha?

JoaoFelipe commented 3 years ago

A criação só deve ser feita para alunos com matriculas ativas, certo?

braganholo commented 3 years ago

Sim!

leomurta commented 3 years ago

@JoaoFelipe @braganholo , será que podemos afirmar isso? Será que essa decisão não poderia ser tomada por quem for rodar a criação de usuários em lote? Talvez usar a própria interface de consulta para, filtrar e ter um botão de "criar usuários" (já tem isso no sapos para matrícula e bolsa. A partir de uma busca se pode gerar um relatório. Nesse caso, seria gerar usuários)? Digo isso pois se vamos deixar os alunos tirarem declarações ou históricos, pode ser interessante permitir usuários inativos terem acesso, para aliviar as solicitações que chegam na secretaria.

leomurta commented 3 years ago

Só precisaria conseguir perceber quais alunos da lista que ainda não tem usuário para gerar só para esses, obviamente. Mas me parece a saída mais flexível (e fácil) discutida até agora.

braganholo commented 3 years ago

Realmente fica bem mais simples dessa forma. Só cuidado para que esse botão esteja disponível apenas para usuários do tipo admin.

JoaoFelipe commented 3 years ago

Me parece uma boa saída. Onde ficaria esse filtro?

Alternativas:

1- Tela Users. Vantagem: já comecei a fazer a versão anterior lá. Desvantagem: teria que implementar filtro do zero lá e daria mais trabalho. O processo ficaria: clicar em "criar para alunos", apareceria um form com uma tabela com todos alunos sem usuário; usar filtros nessa lista; clicar em "criar".

2- Tela Enrollments. Vantagem: dá pra usar a busca que já existe lá e só adicionar campo na busca avançada para verificar "sem usuário". Desvantagem: um aluno pode ter mais de uma matrícula e tenho que ver como fazer a restrição pro botão só aparecer pra admin. Talvez a solução fosse: fazer a busca, clicar em "criar usuário", que mostraria a lista de alunos para selecionar com base no resultado da busca. E depois clicar em "criar" para criar os usuários.

3- Tela Students. Vantagem: existe a garantia de não ter repetição. Desvantagem: a busca existente é mais simples e teria que implementar um tipo de busca avançada (o que não é difícil, considerando que já existe uma pronta). O processo seria o mesmo que o anterior.

4- Cópia de tela students disponível apenas para admin. Vantagem: mesma vantagem anterior, restrição possivelmente mais fácil e daria pra ver a possibilidade de colocar um checkbox do lado de cada registro para já usar o próprio resultado do active scaffold para filtrar. Desvantagem: não sei se o active scaffold suporta isso. O processo seria: fazer a busca (ou não), selecionar os alunos desejados na interface do active scaffold e clicar em "criar usuário".

leomurta commented 3 years ago

Quando falei “filtrar”, pensei nos critérios de busca que já existem em enrollment. A pessoa faria a busca que quisesse. Ao final, clicaria em “criar usuários”. Nós iteraríamos por todos os resultados, pegando o respectivo aluno e vendo se ele já tem usuário. Se não tem, cria. Ao final, poderia informar quantos usuários foram criados, quantos já existiam, etc.

leomurta commented 3 years ago

Isso que eu falei parece ser próximo da solução 2 citada na sua mensagem. Eu tb gostei da solução 3, mas acho que uma busca em aluno será mais pobre, já que algumas coisas como nível, estar ativo ou não, etc. pertence à matrícula. Então meu voto vai para fazer em matrícula, da forma simplificada que eu falei, sem ter que listar alunos e selecionar.

braganholo commented 3 years ago

Eu também prefiro a segunda opção sem ter que selecionar aluno por aluno, conforme Léo mencionou.

Carlos-Eduardo-Cabral-da-Cunha commented 3 years ago

Não temos variável que indique a URL do servidor, mas não sei se o Rails não tem uma forma de extrair isso... pode ser que tenha. @Carlos-Eduardo-Cabral-da-Cunha, você sabe?

Usei um comando root_url que cria um url absoluto na issue #313. Pelo que entendi, o Rails usa uma rota root definida em config/routes.rb e cria um helper adicionando "_url". Testei no ambiente de desenvolvimento, não sei ainda como se comporta em produção.

JoaoFelipe commented 3 years ago

Acho que terminei a issue. Está funcionando da seguinte forma:

  1. Tipo de matrícula tem uma nova coluna "com usuário" que indica se as matrículas deste tipo permitem que alunos tenham usuário:

image

  1. Ao criar uma matrícula deste tipo, o sistema automaticamente cria um usuário e envia um convite para o email cadastrado em estudante l :

image

ATENÇÃO: esse email é enviado direto pela gem DeviseInvitable e a variável redirect_email não tem efeito nenhum. Cuidado ao homologar para não enviar emails a alunos antes do tempo. Se acharem melhor, eu posso tentar ver se tem como configurar o envio para usar essa variável, mas a princípio não dediquei tempo a isso

O template deste email é definido pela variável account_email em erb. A interface de variável não tem um editor bom para isso, e ela basicamente tem que usar duas coisas: @resource que é o objeto user e accept_invitation_url(@resource, invitation_token: @token) que retorna a URL de aceitação do convite.

Após a conta ser criada dessa forma, se o aluno perder o email de convite, ainda dá para entrar/criar senha na opção de resetar senha.

  1. Ao clicar no link, abre uma página para cadastrar senha

image

  1. Com a senha cadastrada, é possível fazer o login. Por enquanto não tem nada na página de aluno:

image

  1. Para matrículas antigas, é possível migrar usando uma ação nova na página de matrículas. Essa ação só está disponível para usuários do tipo administrador ou coordenação.

image

Ao clicar na ação, ela abre esse pequeno formulário que mostra para a visão atual (sujeita a condições de busca) qual é a quantidade de matrículas (6 linhas da tabela), qual é a quantidade de alunos dessas matrículas (5, já que 1 possui duas matrículas), quantos alunos já possuem usuários (0), quantos alunos não possuem email (1), e um combobox para escolher o que deseja adicionar com duas opções:

No caso, a restrição que está impedindo a inserção da aluna "Carol" é o tipo de matrícula "Avulso". Além dessa restrição, existe a restrição de matrículas desligadas

  1. Ao clicar em "Adicionar", o sistema cria usuários para cada aluno e envia o email de convite (do item 2).

  2. Além dessa funcionalidade, usuários criados desta forma ficam associados a alunos e existem restrições para não deixar um aluno ter mais de um usuário e vice versa. Não consegui fazer testes automatizados para essa parte e usei apenas o que já estava feito para usuário de professor. Aparentemente o active scaffold deixa criar usuário com o relacionamento "inválido" (repetir aluno, por exemplo) pela interface, mas esse relacionamente não fica salvo (porém ele também não dá nenhuma mensagem de erro). A restrição funciona e mostra mensagem de erro ao tentar editar usuário. Fiquei algumas horas tentando corrigir isso agora, mas não consegui... Não me parece um problema muito relevante, então vou seguir para a próxima issue.

@Carlos-Eduardo-Cabral-da-Cunha Pode olhar o código no branch feature_student_access

leomurta commented 3 years ago

@JoaoFelipe , excelente trabalho. Muito obrigado. Alguns pontos:

  1. Como faremos daqui para frente? Primeiro o @Carlos-Eduardo-Cabral-da-Cunha audita e testa na sua máquina e com o ok dele eu coloco em homologação? Se passar em homologação, pensei em jogar primeiro para produção na computação e fazer um piloto com alguns alunos mais próximos. Dando tudo certo, jogamos para produção para todos. Sei que é um processo um pouco burocrático, mas assim diminuímos as chances dos problemas se propagarem. Que tal? Em paralelo vc segue nas outras issues, então isso não segura nada.
  2. Sobre o redirect_email, tenho a impressão que seria importante para podermos testar em homologação com tranquilidade. Será que é muito difícil? Sem ele, testar a criação de um usuário não seria problemático, mas testar a migração de vários em lote seria. Além disso, tenho medo de no futuro esquecermos e acabarmos mandando um monte de e-mails para os usuários.
  3. Na mensagem da página inicial, acho que poderia dar esperança aos alunos. Algo como: "Bem-vindo ao Sapos. Você ainda não tem acesso a nada, mas em breve várias funcionalidades interessantes aparecerão aqui para você!"
  4. Pelo que eu entendi, há dois tipos de restrição: (1) checkbox desmarcado no tipo de matrícula e (2) a matricula estar desligada. Não seria interessante termos então opções que desligam cada uma em separado e uma que desliga ambas? Algo como: "X alunos válidos (padrão)", "X alunos válidos, incluindo desligados", "X alunos ativos, incluindo inválidos" e "X alunos, incluindo inválidos e desligados". Outra opção é entender que não faz sentido criar para inválidos, já que isso foi configurado antes. Aí teríamos só duas opções: "X alunos válidos (padrão)" e "X alunos válidos, incluindo desligados". Poderia deixar uma diga textual na página, como fazemos na parte de consulta, falando que se deseja incluir alunos de outros tipos de matrícula, é necessário configurar no tipo de matrícula. Poderia até listar no início uma tabela com cada tipo de matrícula, listando as estatísticas que vc mostra no geral segregadas por tipo e indicando se aquele tipo está configurado para criar usuário. Mas isso só se for fácil de fazer.
braganholo commented 3 years ago

Concordo com o Leo. Os pontos 2 e 4 são bem importantes. Acho que a opção de retirar os alunos inválidos da jogada é boa. Aí deixaria só as opções de alunos válidos e alunos válidos, incluindo desligados.

JoaoFelipe commented 3 years ago

Fiz 2 e 3. Vou deixar o 4 para mais tarde/amanhã

JoaoFelipe commented 3 years ago

Pronto

leomurta commented 3 years ago

Agora a bola está com o @Carlos-Eduardo-Cabral-da-Cunha . Quando eu puder prosseguir, avisem!

nataliacfUFF commented 3 years ago

Oi pessoal,

Essa questão dos inválidos é importante... O que foi considerado como válido? Regulares e especiais?

Abs,

Natalia

Em ter, 10 de ago de 2021 13:35, Leonardo Gresta Paulino Murta < @.***> escreveu:

Agora a bola está com o @Carlos-Eduardo-Cabral-da-Cunha https://github.com/Carlos-Eduardo-Cabral-da-Cunha . Quando eu puder prosseguir, avisem!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gems-uff/sapos/issues/346#issuecomment-896134086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AU6PTJB7XLAZGALBRMT4IK3T4FIMHANCNFSM5A52E35Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

braganholo commented 3 years ago

Oi Natália. Nós deixamos isso configurável, então lá no cadastro de tipo de alunos será possível escolher se aquele tipo de aluno vai ou não ter usuário associado. Os inválidos então são os alunos de tipos que não estão configurados para serem vinculados a usuários. Tem um comentário do João Felipe com um protótipo dessa tela postado há 2 dias.

Carlos-Eduardo-Cabral-da-Cunha commented 3 years ago

Oi Pessoal. Vou baixar para minha máquina para rodar a funcionalidade.

Carlos-Eduardo-Cabral-da-Cunha commented 3 years ago

Agora a bola está com o @Carlos-Eduardo-Cabral-da-Cunha . Quando eu puder prosseguir, avisem!

Funcionou em meu ambiente de desenvolvimento. Fiz alguns testes das funcionalidades e parecem estar ok para teste em homologação. A gem letter_opener_web que o João Felipe instalou ajudou bastante nos testes que enviam emails.

braganholo commented 3 years ago

Fiz alguns testes:

JoaoFelipe commented 3 years ago

Não consegui reproduzir esse ultimo erro aqui, mas encontrei uma possível solução ( https://stackoverflow.com/questions/15486218/how-to-avoid-devise-invitable-from-sending-a-confirmation-email) e já fiz um commit com ela. Verifiquei aqui e tanto convite de matrícula quanto confirmação na criação de usuário continua funcionando. Pode colocar o master em homologação outra vez

João Felipe

Em qua., 18 de ago. de 2021 às 10:36, Vanessa Braganholo < @.***> escreveu:

Fiz alguns testes:

  • coloquei primeiro o redirect email e aí criei um tipo de matrícula que tem usuário associado, criei uma matrícula desse tipo para o João Felipe, mas não recebi o email referente à criação do usuário, e ele também não recebeu. Depois descobri que ele já tinha um usuário associado ao email cadastrado em student, como admin em staging. Aí deu o erro que ele menciona ali acima que não pode ter o mesmo usuário associado a 2 papéis diferentes, e não dá mensagem de erro, então OK (caso raro de acontecer)
  • quando a matrícula que está associada ao usuário é apagada, o usuário não é apagado. João disse que não dá pra fazer um cascading direto pq o relacionamento do usuário é com student e não com matricula. Isso é pouco prioritário, pois na prática a chance de alguém apagar uma matrícula em produção é quase NULA, mas de qq maneira vou documentar isso numa issue nova sem prioridade.
  • quando o email do aluno é atualizado no SAPOS, o email vinculado ao usuário não atualiza também. Não acho que deveria, mas acho importante deixar isso registrado no manual do SAPOS.
  • usei a opção de criar usuários na tela de matrícula de duas formas diferentes, e em ambas ocorreu um comportamento estranho.
    • Peguei duas matrículas existentes e mudei o tipo delas para um tipo que tem usuário vinculado. Depois efetuei a migração usando a opção na tela de matrícula. Os emails que chegaram para esses dois alunos foram diferentes: Um veio como "Instruções para confirmação" e outro veio como "Novo usuário no SAPOS". Não entendi o pq dessa diferença, e o email de "Instrução para confirmação" causa confusão, pois ele nem menciona o SAPOS. O aluno não vai entender porque recebeu aquela mensagem. O ideal seria todos receberem "Novo usuário no SAPOS".
    • Criei um tipo novo de matrícula, sem usuário vinculado, depois vinculei dois alunos a esse tipo, depois voltei no cadastro do tipo e mudei para ter usuário vinculado. Aí usei a opção de migração na tela de matrícula. Ocorreu o mesmo que havia ocorrido no teste anterior: cada aluno recebeu um email diferente. Um veio como "Instruções para confirmação" e outro veio como "Novo usuário 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/346#issuecomment-901121445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQA3IGS3LH62TV4IRNEN3T5OZN7ANCNFSM5A52E35Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

leomurta commented 3 years ago

Já coloquei em homologação. Podem testar.

leomurta commented 3 years ago

Fiz alguns testes em homologação e peguei os seguintes problemas:

  1. O problema reportado pela Vanessa continua: quando já tem N alunos num tipo de matrícula, eu edito o tipo para ele passar a ter usuário e manualmente mando criar usuário, ele manda mensagem correta, com subject "Novo usuário no SAPOS" e conteúdo "Informamos que a sua conta no SAPOS foi criada. Acesse o seguinte link para confirmar e definir sua senha: ...". Contudo, quando crio uma nova matrícula num tipo de matrícula que está configurado para ter usuário, ele manda uma mensagem com subject "Instruções para confirmação" e corpo de mensagem "Você pode confirmar a sua conta através do link a seguir: ...". Essa segunda não faz sentido. O certo seria, em qq uma das situações, mandar a mensagem de "Novo usuário no SAPOS".
  2. Quando rodo a adição manual de usuários, ao terminar a tela continua igual, indicando que tem N usuários possíveis de serem criados. Contudo, eles já foram criados. O ideal seria atualizar aqueles números para eles refletirem a ação que acabou de ser feita. Sem isso, a pessoa fica sem saber se funcionou ou não.
  3. Há casos onde a secretaria cadastrou mais de um e-mail no aluno. Em alguns casos, foi usado ";" como separador. Em outros, foi usado "," como separador. Não ficou claro para mim como isso é tratado.
  4. Uma coisa que tem me incomodado é a redundância do e-mail em aluno e usuário. A minha preocupação é que as notificações sempre vão para os e-mails cadastrados em aluno, mas o login do aluno é com o e-mail em usuário. No momento da criação, são iguais, mas com passar do tempo, podem divergir, gerando inconsistência. Será que temos uma forma de lidar com isso? Talvez na landing page do aluno ele poder trocar o e-mail, e nessa troca a gente atualizar em ambos os locais?

@JoaoFelipe , talvez o ideal seja, depois que vc fizer a nova versão e eu colocar em homologação, vc testar lá, pois assim vc vai conseguir perceber essas coisas.

JoaoFelipe commented 3 years ago
  1. Ainda não consegui reproduzir aqui. Tentei uma outra alternativa que encontrei, pode colocar o master em homologação
  2. Agora o diálogo fecha ao enviar. Quando reabrir, o número atualiza.
  3. Não era tratado. Agora tenta separar o campo por espaço, virgula ou ponto e vírgula e usa o primeiro email para criar usuário
  4. Por enquanto não existe a possibilidade de trocar o email. Acho que não vale a pena barrar essa issue com isso, então criei uma nova issue (#359).

Comecei tentando resolver a (1) usando o mesmo email para confirmação e para convite. Não deu certo, pois o link de confirmação não abre a página com senha. Nessa tentativa, fiz o cherry-pick dos commits da issue #358. Então essa parte também foi para o master e deve ser homologada. A #358 está bem avançada e tem a funcionalidade principal funcionando, mas não está exatamente completa, então quebrei ela também em outra issue (#360)

JoaoFelipe commented 3 years ago

Alias, percebi agora que ainda tenho que fazer uns ajustes para a #348. Devo terminar em 1h. Aviso quando terminar e puder colocar em homologação.

JoaoFelipe commented 3 years ago

Pode colocar em homologação

leomurta commented 3 years ago

Coloquei em homologação. Vc topa dar uma passada antes de mim? Assim, se tiver algum problema vc conseguirá ver diretamente.

JoaoFelipe commented 3 years ago

Ok, vou passar

JoaoFelipe commented 3 years ago

Parece ter funcionado! (tanto essa como #358)

leomurta commented 3 years ago

Obrigado @JoaoFelipe . Já lancei a feature. Por favor, pegue a info que vc detalhou aqui e coloque no manual. Obrigado.