Exibir endereço de e-mail único do pedido ao solicitante

[oiceberg]

Muitos órgãos estão recusando solicitações enviadas por e-mail e reduzindo o "virtual" aos e-SICs. Ao cadastrar um pedido num sistema como o SIC.SP, o solicitante deve cadastrar um e-mail no formulário de cada solicitação. No e-SIC do governo federal, o solicitante deve cadastrar um e-mail no "cadastro de usuário". O Queremos Saber funciona com uma lógica segundo a qual cada solicitação enviada (por e-mail) tem um endereço de e-mail único.

A tecnologia do QS permite que a limitação imposta pelos SICs eletrônicos seja superada. Para isso, basta que o solicitante cadastre como endereço de e-mail o endereço único criado pelo QS para o pedido. O fluxo seria algo assim:

1. Solicitante cadastra solicitação no QS;
2. QS envia automaticamente e-mail para órgão;
3. Órgão responde recusando e-mail ou volta mensagem de erro;
4. Solicitante pega (copia) endereço de e-mail único daquele pedido;
5. Solicitante entra no SIC eletrônico e cadastra (cola) o endereço de e-mail único;
6. Todas as respostas do órgão chegarão no QS automagicamente! ;)

Para essa solução poder ser realizada pelo solicitante, é necessário que o QS permita ao usuário facilmente saber qual é o endereço de e-mail único de cada solicitação por ele próprio criada. Assim, a sugestão é que seja exibido esse endereço de e-mail no próprio pedido quando o usuário estiver logado.

[everton137]

Esse ticket é importante.

[vitorbaptista]

Muito boa sua ideia, @leandrosalvador. Um ótimo hack 😃

O problema que vejo é que, se cadastrar o e-mail do pedido no QS, no esic, pode vir algum lixo. Por exemplo, algum esic confirma o e-mail enviando um e-mail quando você se cadastra? Se sim, isso ficaria atrelado ao pedido. E, pior, cada e-mail é único. Se você cadastra um e-mail pra um pedido, teria que mudá-lo pro próximo. Será que isso não quebra essa ideia? O que vocês acham?

Estava pensando em algo bem mais complicado. Tinha pensado noutro sistema que gerasse um email do tipo esicsp@queremossaber.org.br. Daí, todo e-mail enviado para aí, já iria pro sistema do esic de SP usando uma conta nossa. As respostas poderiam vir no formato esicsp+@queremossaber.org.br. Dessa forma, pro usuário do QS, seria indiferente se o órgão aceita ou não pedidos via e-mail.

Poderia ser até interessante pro AdoteUmPedido.info. Como os pedidos viriam em uma conta nossa nos esics, o solicitante poderia se manter anônimo.

Só arranjar tempo...

[oiceberg]

@vitorbaptista até onde sei nenhum eSIC pede confirmação não. Pelo que entendi o e-mail único gerado pelo QS é para cada pedido, e não para cada órgão, o que faz sentido. O histórico de correspondências eletrônicas deve mesmo estar atrelado ao que é o objeto central ("fact table") do QS: o pedido.

Se gerarmos um endereço no formato esicsp+@queremossaber.org.br, te pergunto: será que isso não vai acabar por desconectar os dois objetos: (i) pedido e (ii) órgão demandado? Porque o eSIC (governo federal) e o SIC.SP (governo estadual de SP) são os dois sistemas intermediários, mas eles, em si, não representam cada destinatário (órgão público). São meros roteadores.

Como os e-SICs da vida não aceitam entradas por e-mails, se toda resposta ao QS vier para um e-mail único criado para cada respectivo e-SIC, salvo engano meu, acontecerá que todos os mais variados pedidos enviados para aquela unidade federativa ficarão todos juntos e misturados, não?

Agora, se entendi a ideia, a vantagem seria que o usuário já saberia que se for fazer um pedido para algum órgão de SP via SIC.SP, bastaria ele cadastrar como seu próprio e-mail o e-mail esicsp+xpto@queremossaber.org.br.

O que não sei se seria possível é estabelecer uma lógica no QS onde, mesmo sem um pedido ter sido criado manualmente na plataforma (ou seja, ter remetente, destinatário, conteúdo, assunto, datetime, etc.), daria para criar um módulo que faça o QS, ao receber uma mensagem enviada para o e-mail X, criar ele próprio todo um pedido "do zero".

Em outras palavras, o usuário do QS não enviaria um pedido por e-mail nesse caso, mas apenas cadastraria um pedido que deverá chegar por e-mail a seguir (enviado pelo e-SIC ao QS), assim que ele cadastrá-lo no e-SIC. Mas daí, a este e-mail X, já estaria conectado tudo que o QS precisa saber: usuário-remetente, órgão-destinatário, assunto e conteúdo. É isso? :D

[vitorbaptista]

@leandrosalvador Relendo sua resposta, acho que você não entendeu minha ideia. Por exemplo, digamo que o Ministério da Justiça exija que os pedidos sejam feitos através do eSic. Sabendo disso, nós, do QS, criaríamos um e-mail do tipo mj@queremossaber.org.br. Quando alguém envia um e-mail para esse endereço, existiria um programa que leria este e-mail e criaria um pedido com o conteúdo no portal do eSic. Daí, quando o MJ respondesse para esse pedido (no sistema do eSic), esse sistema iria raspar essa resposta, transformar num e-mail, e responder de volta ao pedinte, através do mj@queremossaber.org.br.

Não estou conseguindo explicar bem, mas a ideia é relativamente simples. Seria um sistema, separado do QS, que criaria uma "API" para o eSic. A forma de usar essa API é através do e-mail. Um problema (talvez) é que todos os pedidos ficariam no nome de uma única pessoa: a gente.

Mais uma vez, o processo é:

• Envia pedido via QS
• QS manda e-mail pra mj@queremossaber.org.br
• O programinha recebe o e-mail e cria pedido no eSic, enviando de volta ao QS o número de protocolo e o que mais for necessário

Quando o MJ responder, teríamos:

• MJ responde para mj@queremossaber.org.br
• O programa analisa a mensagem para saber de qual pedido é, e encaminha pro e-mail do QS daquele pedido.

A dificuldade em implementar isso é fazer o scrapper pro eSic, e esse servidor de e-mail. Mas não é nada demais. A grande vantagem é que é transparente pros usuários do QS. Para eles, estão enviando um pedido como qualquer outro.

Sacou?