-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relatório: oferecer diferentes opções de agrupamento de resultados #21
Comments
Para o meu uso pessoal (sim, eu também uso o Ro-DOU) eu prefiro da forma como está hoje. Isto é, um e-mail só com todos os resultados, independente da fonte. Até porque a fonte está bem explícita no corpo do e-mail. Acho que essa feature poderia ser mais uma opção no arquivo de configuração yaml para que cada um escolha se prefere receber um e-mail só consolidado ou receber vários e-mails separados. Só para entender melhor, a ideia dessa feature seria, para cada diário oficial de município, mandar um e-mail em separado? Ou todos os do QD seriam em um e-mail só? Do seu texto, interpretei que é a segunda opção, embora ache que faria mais sentido, se for separar, separar por fonte (i.e. um e-mail para o D.O.U., outro para o D.O.M. de Belo Horizonte, outro para o D.O.M. de Recife, etc.). |
E mesmo que seja em um único email vc prefere agrupado pelo termo, como é hoje, ou agrupado por município? Pra mim o lance de separar em vários emails por município não parece interessante. Eu vejo que a questão principal é a forma de agrupamento, se por termo, ou por organização (talvez essa seja a configuração disponível no yaml). E aí se for por organização então separa o federal dos municipais. Tudo poderia continuar sendo um único email diário do Ro-dou, mudando apenas a organização do email. Separar em mais de um email pode fazer algum sentido em certos cenários. Talvez isso possa ser tb uma futura funcionalidade. |
Faz sentido ter a opção de configurar a forma de agrupamento, se por termo ou por ente federativo. Porém, por organização creio não ser possível, com a estrutura atual (raspagem da pesquisa) e sem requisições e processamento adicionais. Seria necessário ler o diário e tentar identificar qual organização (Ministério, Secretaria de Estado, etc.) é responsável pela publicação de cada ato. Com quem está pedindo isso, será que agrupar os atos de forma diferente no e-mail já seria suficiente para atender às suas necessidades? Aliás, tem mais um ponto a se considerar ao pensar na organização do relatório é que, da forma como está implementado hoje, o relatório agrupa itens que são coisas diferentes. No Diário Oficial da União, cada item do relatório é um ato (Decreto, Portaria, Resolução, etc.). Já nos resultados do QD não há essa separação por ato e cada item é a própria edição do diário daquele dia. |
Quando me referi a organização eu me referi ao nível mais alto, ou seja cada município é uma "organização". Também acho que agrupar por tipo de documento é interessante mas inviável nesse momento.
Então acho que podemos fechar esse requisito nessa linha de adicionar a forma de agrupamento.👌🏽
Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.
Enviado via Proton Mail para dispositivos móveis
…-------- Mensagem Original --------
Em 8 de fev de 2023 18:16, Augusto Herrmann escreveu:
Faz sentido ter a opção de configurar a forma de agrupamento, se por termo ou por ente federativo.
Porém, por organização creio não ser possível, com a estrutura atual (raspagem da pesquisa) e sem requisições e processamento adicionais. Seria necessário ler o diário e tentar identificar qual organização (Ministério, Secretaria de Estado, etc.) é responsável pela publicação de cada ato.
Com quem está pedindo isso, será que agrupar os atos de forma diferente no e-mail já seria suficiente para atender às suas necessidades?
Aliás, tem mais um ponto a se considerar ao pensar na organização do relatório é que, da forma como está implementado hoje, o relatório agrupa itens que são coisas diferentes. No Diário Oficial da União, cada item do relatório é um ato (Decreto, Portaria, Resolução, etc.). Já nos resultados do QD não há essa separação por ato e cada item é a própria edição do diário daquele dia.
—
Reply to this email directly, [view it on GitHub](#21 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAJP2GYPRULUKBBBD4UX7YTWWQEJNANCNFSM6AAAAAAUJBZR6Q).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Concordo. Seria uma opção para escolher entre o agrupamento por termo ou por ente federado. O que acha de fazer assim? dag:
report:
group_by: term para agrupar por termo, e dag:
report:
group_by: federated_entity para agrupar por ente federado (União, Estado, Distrito Federal ou Município). |
De acordo com essa última proposta, alterei o título da issue. |
Essa proposta de sintaxe pro YAML é uma boa! |
Hoje já tem gente solicitando diferentes formas de agrupamento dos relatórios. Isso reforça a necessidade desta issue. Por ora, o @edulauer contornou essa necessidade criando uma pesquisa por órgão. Mas assim o yaml fica de mais difícil manutenção, pois os termos de busca ficam repetidos em cada pesquisa. O ideal é fazer como na proposta acima. |
As mudanças realizadas por este PR criaram a opção do Ro-dou realizar as buscas também no Querido Diário. Com isso é possível configurar um clipping para que realize a pesquisa dos termos tanto no QD quanto no DOU. A implementação atual produz um email contendo os documentos encontrados em ambas as fontes ordenados por termo. Dessa forma, para cada termo pesquisa, o resultado final é a mistura dos resultados de cada uma das fontes.
Seguindo a sugestão de um usuário assíduo do Ro-dou trago a proposta de mudar esse resultado final produzido para facilitar a diferenciação entre os resultados produzidos pelo DOU e os resultados produzidos pelo QD. A solução que proponho é simplesmente separar os resultados em emails individuais. Seguindo esta implementação um benefício extra é de que o usuário conseguirá identificar rapidamente se houveram resultados em cada uma das fontes sem necessariamente abrir o email.
The text was updated successfully, but these errors were encountered: