[robertatakenaka]

O que esse PR faz?

Adiciona uma área de relatórios públicos ao site, acessível em /report/, e o primeiro relatório dessa área: Disponibilidade de dados, que mostra a quantidade de artigos por status de disponibilidade de dados (Article.data_availability_status), por ano, com totais e porcentagens.

Funcionalidades:

• Página inicial de relatórios públicos, que lista os relatórios disponíveis a partir de um registro único (PUBLIC_REPORTS)
• Relatório de disponibilidade de dados com filtros por coleção, periódico e intervalo de ano de publicação online
• Agrupamento por ano do fascículo (legenda bibliográfica) ou por ano de publicação online
• Filtros dependentes: os periódicos e anos oferecidos se ajustam à coleção/periódico selecionados, via endpoint JSON
• Exportação em CSV preservando os filtros aplicados
• Cache de 1 hora nas views do relatório e das opções, já que a consulta percorre toda a tabela Article
• Traduções em inglês, espanhol e português

Onde a revisão poderia começar?

Indique o caminho do arquivo e o arquivo onde o revisor deve iniciar a leitura do código.

1. report/data_availability.py — lógica do relatório (filtros, agrupamento, totais e porcentagens)
2. report/test_data_availability.py — testes do módulo
3. report/forms.py — DataAvailabilityFilterForm
4. report/views.py — report_index_view, data_availability_view, data_availability_options_view e exportação CSV
5. report/urls.py e config/urls.py — rotas
6. report/templates/report/ — public_base.html, index.html e data_availability.html

Como este poderia ser testado manualmente?

Estabeleça os passos necessários para que a funcionalidade seja testada manualmente pelo revisor.

1. Executar os testes: python manage.py test report.test_data_availability
2. Compilar as traduções: python manage.py compilemessages
3. Acessar /report/ sem estar autenticado e verificar se o relatório "Disponibilidade de dados" aparece na lista
4. Abrir o relatório e conferir a tabela por ano, com colunas de contagem e porcentagem por status e a linha de total
5. Selecionar uma coleção e verificar se as listas de periódicos e de anos são atualizadas
6. Aplicar filtros de periódico e de intervalo de ano de publicação online e conferir os números
7. Alternar o agrupamento entre "Ano do fascículo (legenda bibliográfica)" e "Ano de publicação online"
8. Informar um ano inválido (ex.: 20a5) e verificar se o relatório continua sendo exibido, ignorando apenas esse filtro
9. Clicar em "Baixar CSV" e verificar se o arquivo respeita os filtros aplicados e usa ; como separador
10. Aplicar filtros que não retornem artigos e verificar a mensagem "Nenhum artigo encontrado para os filtros selecionados."
11. Trocar o idioma da interface (pt_BR, es, en) e conferir as traduções

Algum cenário de contexto que queira dar?

Indique um contexto onde as modificações se fazem necessárias ou passe informações que contextualizam o revisor a fim de facilitar o entendimento da funcionalidade.

O relatório responde à necessidade de acompanhar a adoção da declaração de disponibilidade de dados nos artigos publicados, por coleção e por periódico, sem exigir acesso à área administrativa.

O ano do fascículo (legenda bibliográfica) e o ano de publicação online podem divergir, por exemplo em publicação contínua ou ahead of print. Por isso o filtro de intervalo se aplica sempre ao ano de publicação online, enquanto o agrupamento das linhas pode usar qualquer um dos dois anos. Essa distinção está explicada na própria página do relatório.

Para adicionar novos relatórios públicos, basta incluir a rota em report/urls.py e uma entrada em PUBLIC_REPORTS em report/views.py.

Como o relatório é público e consulta toda a tabela Article, as views usam cache_page com validade de 1 hora; alterações recentes nos artigos podem levar até esse tempo para aparecer.

Screenshots

Quando aplicável e se fizer possível, adicione screenshots que remetem à situação gráfica do problema que o pull request resolve.

Quais são os tickets relevantes?

Indique uma issue à qual o pull request faz relacionamento.

Referências

Indique as referências utilizadas para a elaboração do pull request.

• Django — cache por view (cache_page): https://docs.djangoproject.com/en/stable/topics/cache/#the-per-view-cache
• Django — internacionalização de URLs (i18n_patterns): https://docs.djangoproject.com/en/stable/topics/i18n/translation/#language-prefix-in-url-patterns
• SciELO — Guia para declaração de disponibilidade de dados (Data Availability Statement)

---

Segurança da informação (NSI.04)

Seção obrigatória. Marque as opções aplicáveis e justifique quando necessário. Referência: NSI.04 - Norma de Desenvolvimento Seguro.

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Sim — descreva os controles de proteção aplicados (criptografia, mascaramento, anonimização, etc.):
• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Sim — descreva o que mudou e por quê:
• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Sim — as novas dependências foram verificadas no SBOM/Trivy sem vulnerabilidades críticas/altas em aberto?
  • Verificado e aprovado
  • Pendente / vulnerabilidade aceita com justificativa:
• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Sim — link do job:
• Não aplicável a este PR (justifique):

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Sim — confirme que há sanitização/parametrização (prepared statements, escaping, etc.):
• Não

Este PR expõe novos endpoints, telas ou serviços?

• Sim — HTTPS obrigatório está garantido e o acesso segue o princípio de menor privilégio? Expõe as telas /report/ e do relatório de disponibilidade de dados, além do endpoint JSON de opções dos filtros. São públicos por definição, somente leitura (GET) e retornam apenas contagens agregadas de artigos e listas de periódicos/anos, sem dados pessoais. Os parâmetros de entrada são validados pelo formulário e usados apenas via ORM. Servidos sob o mesmo HTTPS do site.
• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado
• Sim (bloquear merge e corrigir antes de prosseguir)

[Rossi-Luciano]

Rodei os 33 testes de report.test_data_availability no ambiente local: todos passam. Testei também na interface (índice /report/, relatório, os dois agrupamentos, filtros e CSV) e está funcionando.

Deixei um ponto bloqueante (cache, em views.py) e dois não bloqueantes, comentados nas linhas correspondentes.

Na descrição do PR ficaram pendentes:

• o item da NSI.04 sobre o pipeline de segurança (SonarQube / Trivy), sem nenhuma opção marcada;
• screenshots;
• a issue relacionada.

[Rossi-Luciano]

Bloqueante: a chave do cache_page inclui a query string inteira. Parâmetros que o form ignora, ou apenas os mesmos parâmetros em outra ordem, geram uma nova entrada e refazem as agregações sobre Article.

Medi localmente (cache Redis, como em production.py), contando as consultas SQL por requisição:

requisição	consultas em article_article
URL A	5
URL A, repetida	0 (cache)
A + &x=1	5
A + &x=2	5
A com os parâmetros reordenados	5

Como o relatório é público, basta variar um parâmetro qualquer para ir sempre ao banco. Também afeta o uso normal: links com os mesmos filtros em ordem diferente não compartilham o cache. O mesmo vale para data_availability_options_view.

Sugestão: em vez de cache_page, guardar em cache o resultado de build_report / pub_years_for com uma chave montada só a partir dos filtros válidos (form.filters()), por exemplo:

key = "data_availability:{}:{}:{}:{}:{}".format(
    getattr(filters["collection"], "pk", ""),
    getattr(filters["journal"], "pk", ""),
    filters["year_from"] or "",
    filters["year_to"] or "",
    filters["group_by"],
)
report = cache.get_or_set(
    key,
    lambda: data_availability.build_report(queryset, group_by=filters["group_by"]),
    DATA_AVAILABILITY_CACHE_SECONDS,
)

Assim, parâmetros estranhos e a ordem deixam de importar.

[Rossi-Luciano]

Não bloqueante: com year_from maior que year_to (ex.: 2025 a 2020), o intervalo passa sem aviso e o relatório sai vazio ("Nenhum artigo encontrado..."). Uma opção é inverter os dois. A comparação como string é segura porque o RegexField garante 4 dígitos:

Suggested change

	return {
	"collection": data.get("collection"),
	"journal": data.get("journal"),
	"year_from": data.get("year_from") or None,
	"year_to": data.get("year_to") or None,
	"group_by": data.get("group_by") or GROUP_BY_ISSUE_YEAR,
	}
	year_from = data.get("year_from") or None
	year_to = data.get("year_to") or None
	if year_from and year_to and year_from > year_to:
	year_from, year_to = year_to, year_from
	return {
	"collection": data.get("collection"),
	"journal": data.get("journal"),
	"year_from": year_from,
	"year_to": year_to,
	"group_by": data.get("group_by") or GROUP_BY_ISSUE_YEAR,
	}

[Rossi-Luciano]

nit (opcional): o cabeçalho da tabela (e o CSV) mostra o código do status (data-available, not-processed...), e o rótulo traduzido aparece só no tooltip e na legenda. Para quem acessa o relatório público, talvez fosse mais legível exibir o rótulo no cabeçalho.