Notificações e verificação assíncrona de pendências

[braganholo]

Permitir consultas diárias, semanais, etc e envio de relatório por email, caso o resultado da consulta seja não vazio. Exemplo: quem pediu banca e não defendeu, passados 45 dias.

[braganholo]

Tarefa alocada ao projeto final do Luis e João Felipe.

[JoaoFelipe]

Estamos vendo os exemplos de notificações que foram faladas e parece que dá pra dividir em notificações síncronas e assíncronas.

Sincronas:

• notificar o orientador que um novo aluno foi cadastrado como orientando dele
• notificar o orientador que o orientando dele tem uma nova nota de
  disciplina cadastrada

Assíncronas:

• notificar o aluno e o orientador dele de que ele precisa entrar com
  pedido de banca ou prorrogação na próxima reunião do colegiado [como saber qual é a reunião do colegiado? podemos fazer notificar 1 mês e 1 semana antes do prazo]
• notificar o coordenador que os alunos X Y e Z precisam pedir banca [quantos dias antes, é necessário?]
• notificar o coordenador que os alunos X Y e X pediram banca mas
  ainda não foram desligados, passados 45 dias do pedido de banca

Dúvida:

• notificar o professor responsável por uma disciplina que as notas da
  disciplina dele foram lançadas (ou foram alteradas)
  [Estamos em dúvida se colocamos notificação síncrona a cada alteração ou uma assíncrona verificando todas as alterações em notas no final do dia]

Para essa Issue, vamos fazer as assíncronas. Depois criamos outra Issue para síncronas.

Tem alguma faltando, ou alguma que vocês achem que não é possível atualmente?

[braganholo]

notificar o aluno e o orientador dele de que ele precisa entrar com
pedido de banca ou prorrogação na próxima reunião do colegiado [como saber
qual é a reunião do colegiado? podemos fazer notificar 1 mês e 1 semana
antes do prazo]

A reunião acontece sempre na última quarta-feira de cada mês. Mas talvez
na notificação vcs devessem permitir o cadastro do momento em que desejam
que a notificação seja enviada. Poderia ser em uma data específica, ou em
uma data desse tipo (primeira segunda-feira de cada mês, última
quarta-feira do mês a cada dois meses -- vejam que aqui tem a data e a
periodicidade também, que poderia ser semanal, quinzenal, mensal, anual,
etc. Daria para se inspirar no cadastro de evento recorrente da agenda do
google. Vejam lá as opções que eles oferecem.

• notificar o coordenador que os alunos X Y e Z precisam pedir banca
  [quantos dias antes, é necessário?]

Se vcs deixarem que isso seja cadastrado, como comentei ali acima, fica
genérico o suficiente para ser aplicado a qualquer situação. Mas de qq
maneira, para responder a sua pergunta, pode ser com 1 mês e 1 semana de
antecedência.

• notificar o coordenador que os alunos X Y e X pediram banca mas
  ainda não foram desligados, passados 45 dias do pedido de banca

Dúvida:

• notificar o professor responsável por uma disciplina que as notas da
  disciplina dele foram lançadas (ou foram alteradas) [Estamos em dúvida se
  colocamos notificação síncrona a cada alteração ou uma assíncrona
  verificando todas as alterações em notas no final do dia]
  .

Eu sugiro que seja a cada alteração. É mais seguro.

Para essa Issue, vamos fazer as assíncronas. Depois criamos outra Issue
para síncronas.

Tem alguma faltando, ou alguma que vocês achem que não é possível
atualmente?

Que eu me lembre, não. Em relação às notas lançadas, vcs podem notificar o
aluno também, e não só o orientador dele. Assim evita deles ficarem
perguntando na secretaria se a nota já saiu.

[leomurta]

O ideal seria tentar generalizar o problema, pensando que uma notificação tem um conteúdo, um (ou mais) destinatários e uma data (é só isso ou tem algo mais?). O conteúdo poderia ser o resultado de um SQL (ou alguma outra linguagem de consulta). O destinatário também. A data poderia ser algo parametrizável. Isso permitiria fazer essas notificações definidas por vocês ou outras que se tornassem necessárias.

Lembrem que o Everton irá tratar a questão de consultas complexas. Então vcs poderiam simplesmente abstrair e assumir que há consultas cadastradas no BD (podemos colocar na mão enquanto não temos consultas complexas) ou fazer uma tela básica para cadastrarmos, mas sem nenhum tipo de validação.

No mais, quanto a separação em síncronas e assíncronas, achei legal. Em relação às notas, uma notificação que acho fundamental é ao professor que ministrou a disciplina. Isso acaba sendo até um mecanismo de proteção: se alguém troca a nota, o professor fica sabendo. Pensem sempre quem é o "dono" do dado. No caso, é o professor que deu a nota e o aluno que recebeu. O orientador é interessado, mas esses outros dois são mais.

[lvieirajr]

Leo,
é exatamente isso que está acontecendo atualmente no notifier.rb
Ele recebe um bloco de código ruby (que pode ser a execução de uma query SQL)
e esse bloco é executado e nos retorna uma lista de hashes, onde cada hash contem um destinatário um subject e uma mensagem.
Por exemplo:
Poderiamos buscar no model PhaseCompletion todos os alunos que tem que pedir banca daqui a 30 dias, fazemos a consulta sql, e populamos um hash para cada um desses alunos que foi retornado na lista, sendo o campo To: o email do aluno retornado, subject: 'Prazo limite do Pedido de Banca' e body: 'Você tem até 30 dias para fazer o seu pedido de banca'

E para cada consulta um codigo desse tipo seria feito, o que me parece razoavelmente simples, especialmente agora que temos todos os prazos salvos no banco, facilitando a consulta.

Ou as vezes até mesmo uma consulta apenas faria mais de 1 notificacao, neste caso poderiamos alem de notificar o aluno, notificar também o orientador dele, e notificar ao coordenador de todos os alunos que ainda faltam pedir banca, tudo em apenas uma das notificacoes

[leomurta]

Funcionou com wget --spider --no-check-certificate https://sel.ic.uff.br/sapos. Vou ajustar o script.

[JoaoFelipe]

Parece que a configuração não funcionou. =/

Tentei instalar o apache com passenger aqui para tentar reproduzir o erro localmente, seguindo a wiki https://github.com/gems-uff/sapos/wiki/Explained-Quick-install-for-production, mas não funcionou =/
Ficou mostrando a página "It works" do apache.
Alguma sugestão do que pode ser?

[leomurta]

Vc está na UFF? Eu posso criar uma conta para vc no servidor. Assim, vc consegue ver a configuração lá.

[JoaoFelipe]

Não estou =/

Bom, vou tentar fazer a solução que mostra lá na Issue

[JoaoFelipe]

Consegui rodar o passanger localmente aqui (usando bundle exec passenger start -p 3000) e usar a "gambiarra" que colocaram na issue.
Ele até "funciona", mas não é muito confiável... O passenger consegue matar a tarefa, mas na próxima requisição, a "gambiarra" reinicia o scheduler.
O problema disso é que tem que ter tido uma requisição próxima do momento de execução das noificações.

Bom, eu só executei o código do modo que estava, sem nenhuma configuração. Vou ver se consigo usar o PassengerMinInstances 1 localmente para ver qual é o resultado junto da gambiarra.

Se não der certo, só consigo ver as seguintes soluções:
1- Fazer deploy usando algo diferente de passenger
2- Tirar o start_at e colocar uma frequencia de execução pequena (10 min). Quando tiver uma requisição, a gambiarra vai iniciar a tarefa que vai executar em 10 minutos.
3- Criar um script paralelo ao servidor que faça uma requisição 3 minutos antes do programado para o start_at, garantindo que a gambiarra sempre vai iniciar a tarefa antes do momento de execução
4- Criar um Notificador standalone, que não seja executado pelo passenger. A dificuldade deste último seria executar o rails (carregar db, modelos, monkeypatches...), sem executar a parte do servidor

Alguma outra opção?

[leomurta]

Vamos lá... que tal termos o wget --spider URL no crontab da máquina, e URL sendo uma URL especial (https://sel.ic.uff.br/sapos/notify), que quando é chamada verifica se tem alguma pendência e manda as notificações? Assim, se alguém chamar na mão essa URL, não terá efeito colateral. Por outro lado, teríamos toda a flexibilidade do cron para dizer em qual frequência queremos a verificação.

Mas independentemente disso, eu queria entender o que não está dando certo. Pelo que testei, o Passenger está mantendo um processo vivo.

[JoaoFelipe]

Essa opção de ter uma url para executar notificações me parece boa e simples de fazer.

O que não ta dando certo é o seguinte:
O passenger está matando o processo do rufus. Não sei qual é o processo que ficou vivo, mas o processo que estava marcado para executar as 10:00 não foi executado.
Pensando agora, o que pode ter acontecido foi eu ter criado um novo processo pra iniciar as 10:00, mas o passenger manteve o antigo que estava marcado para as 20:00 (mesmo depois do rufus desabilitar ele)
Se quiser verificar se foi isso mesmo, você pode reiniciar o servidor. Botei o horário da próxima execução para 21:00.

[leomurta]

Coloquei para 3:00 e depois reiniciei o Apache. Estou assumindo que ao reiniciar o Apache o rufus entra no ar. Vamos ver no que dá.

[lvieirajr]

Aparentemente nao enviou.
Pelo menos eu nao recebi nada

[leomurta]

Estou achando que a ideia da url que verifica pendências assíncronas com uma linha no cron da máquina funcionará bem.

[lvieirajr]

concordo, so acho q deveria ter um token nessa requisicao pra nao deixar
qualquer um ficar fazendo request

[JoaoFelipe]

O que é melhor: deixar só a a url, ou manter o rufus com uma opção de ativar/desativar?

[leomurta]

Acho que deixar só a url, para não complicarmos as coisas. Aí poderia editar o guia de instalação falando que é necessário incluir no cron algo para ativar as notificações assíncronas.
Quanto ao token, será que é de fato necessário? Qual seria o efeito colateral de alguém externo fazer a requisição?

[lvieirajr]

O processamento das notificações, é um tanto quanto "pesado", são muitas
consultas ao banco etc...
Se alguem por algum motivo resolver disparar uma quantidade grande de
requests pra essa URL,
Iria iniciar uma quantidade enorme de chamadas ao banco, chamadas de
funções, podendo causar falhas no sistema.

Não acredito que isso vá acontecer, até por ser um sistema interno onde
poucas pessoas tem acesso,
mas no meu ponto de vista, prevenir é melhor do que remediar.

[JoaoFelipe]

Não acho que o processamento de notificações seja pesado... Tem menos de 10 notificações cadastradas no banco e a busca delas só é executada se a pré-busca pela data considerar que está na hora delas serem executadas.

De qualquer forma, não é muito dificil fazer essa verificação...

[leomurta]

Bom, vcs decidem. Se forem fazer o token, ele poderia ser uma variável a ser configurada em um arquivo, como é o caso do config/initializers/secret_token.rb.

[JoaoFelipe]

Fiz a url sem o token.
Luis, se quiser usar o token, pode colocar lá.
Acho que o token poderia ficar dentro do proprio arquivo secret_token

Outra opção é ter uma variavel de ambiente que seja o token... Se a variavel não estiver definida não usa o token.
Acho que isso facilitaria a criação do cron

[leomurta]

Realmente, é melhor a ideia da variável de ambiente.
Quando estiver pronto e for para colocar em homologação, avisem.

[lvieirajr]

Acho que pode botar em homologação como está, bom para ja validarmos se
esta solução será suficiente.
Enquanto isso eu vou dando uma olhada no processo de usar o token.

[leomurta]

Coloquei. Mas qual é a url? Se for https://sel.ic.uff.br/sapos-homologacao/notify, parece que não está funcionando.

[JoaoFelipe]

https://sel.ic.uff.br/sapos-homologacao/notifications/notify

[leomurta]

As mensagens que chegaram foram por que eu cliquei no link. Agora peço que ninguém clique no link. Eu programei o cron da máquina para chamar de manhã (em torno de 6h).

[leomurta]

Ah, programei tb uma notificação de teste como diária.

[leomurta]

Funcionou!

Vcs poderiam atualizar o wiki de instalação em produção dizendo que para habilitar as notificações assíncronas é necessário criar o arquivo /etc/cron.daily/sapos com o seguinte conteúdo:

#!/bin/sh
wget --spider --no-check-certificate --quiet http://www.foo.com/sapos/notifications/notify