Skip to content

Corrige a obtenção dos pdfs do pacote do Upload v3.x - #1036

Merged
robertatakenaka merged 4 commits into
scieloorg:rcfrom
robertatakenaka:rc_fix_pdf_path
Aug 4, 2026
Merged

Corrige a obtenção dos pdfs do pacote do Upload v3.x#1036
robertatakenaka merged 4 commits into
scieloorg:rcfrom
robertatakenaka:rc_fix_pdf_path

Conversation

@robertatakenaka

@robertatakenaka robertatakenaka commented Aug 3, 2026

Copy link
Copy Markdown
Member

O que esse PR faz?

Corrige a leitura do conteúdo dos renditions (PDFs) durante a publicação de pacotes, que anteriormente falhava ao localizar o arquivo dentro do .zip. Também: (a) permite localizar um Article já existente e reservas de PID (PidReservation) considerando variações/nomes depreciados de sps_pkg_name, evitando duplicidade de registros quando o nome do pacote muda entre versões; (b) adiciona fallback para obtenção da data de publicação do artigo quando article_publication_date não está disponível; (c) adiciona parâmetro force_update para permitir reprocessar o SPSPkg mesmo quando já registrado e válido no Core; (d) evita chamadas de upload ao storage com conteúdo vazio/inexistente; (e) atualiza a dependência packtools para 4.16.11; (f) remove logs de depuração (logging.info) sem valor em produção.

Onde a revisão poderia começar?

upload/models.py, no método Package.renditions (leitura de rendition["path_in_zip"] em vez de rendition["name"]), que é a origem principal do problema relatado (PDFs não encontrados).

Como este poderia ser testado manualmente?

  1. Fazer upload de um pacote SPS com renditions (PDFs) cujo name de exibição seja diferente do caminho do arquivo dentro do .zip.
  2. Avançar o pacote até a etapa de publicação (QA e/ou público) e confirmar que o PDF é lido/exibido corretamente, sem erros.

No entanto, foi identificado um bug no minio que será tratado no PR ...

Algum cenário de contexto que queira dar?

A questão principal é que os PDFs não eram encontrados. Isso ocorria porque a leitura do conteúdo do rendition usava a chave name (nome de exibição) ao invés do caminho real do arquivo dentro do .zip (path_in_zip), causando falha na recuperação do conteúdo do PDF durante a publicação. As demais alterações neste PR (variações de nome de pacote, fallback de data de publicação, force_update) foram necessárias para dar suporte e consistência ao fluxo de atualização de pacotes com o packtools 4.16.11.

Screenshots

Quando aplicável, anexar prints do erro anterior (PDF não encontrado) e da publicação funcionando corretamente após a correção.

Quais são os tickets relevantes?

Issue relacionada: PDFs de renditions não encontrados durante a publicação de pacotes (ver issue acima).
FIx #1035

Referências

  • packtools 4.16.11 (changelog/release notes referentes a pkg_name_variations, deprecated_sps_pkg_name_list, get_complete_publication_date e estrutura de renditions com path_in_zip)

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: atualização do packtools de 4.16.8 para 4.16.11 (dependência interna do projeto SciELO) — verificação pendente de execução do pipeline
  • 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): preencher após execução do pipeline no PR

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?
  • 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)

## Propósito
Atualizar a dependência packtools de 4.16.8 para 4.16.11, disponibilizando
recursos necessários para os ajustes subsequentes em Article, SPSPkg e
Package (pkg_name_variations, deprecated_sps_pkg_name_list,
get_complete_publication_date e path_in_zip em renditions).

## Solução técnica
Bump de versão da referência git no requirements/base.txt
(packtools.git@4.16.8 -> packtools.git@4.16.11).
…orage

## Propósito
Evitar chamada de upload_to_the_cloud com content=None quando o item não
possui conteúdo disponível (após KeyError tratado em item["content"]).

## Solução técnica
Adicionado `if not content: continue` antes da chamada de
upload_to_the_cloud, pulando itens sem conteúdo em vez de tentar enviá-los.
…xistente

## Propósito
Corrigir falha em localizar um Article já existente quando o sps_pkg_name
do pacote mudou entre versões (nomes depreciados), o que causava criação
de registros duplicados em vez de atualização do existente.

## Solução técnica
- get_first passa a aceitar o parâmetro name_list e inclui
  Q(sps_pkg__sps_pkg_name__in=name_list) na busca.
- create_or_update tenta obter xml_with_pre.pkg_name_variations; se o
  atributo não existir (AttributeError), monta a lista manualmente a
  partir de sps_pkg_name + deprecated_sps_pkg_name_list, e passa essa
  lista para get_first.
## Propósito
Corrigir múltiplos pontos relacionados à publicação de pacotes:
leitura incorreta do conteúdo de renditions dentro do zip, ausência de
fallback na extração da data de publicação, impossibilidade de forçar
reprocessamento do SPSPkg já registrado no Core, e falha na localização
de PidReservation/pid_v2 quando o nome do pacote mudou entre versões.
Também remove logs de depuração (logging.info) que não agregam valor
em produção e renomeia variável para refletir seu real significado.

## Solução técnica
- upload_package_directory_path: renomeia variável sps_pkg_name para
  xml_name, já que representa o nome do arquivo e não necessariamente
  o nome do pacote SPS.
- PackageZip.xmls: remove logging.info supérfluo.
- Package.renditions: passa a ler o conteúdo via
  zf.read(rendition["path_in_zip"]) em vez de rendition["name"], já que
  o path dentro do zip pode diferir do nome exibido.
- Package.set_pid_v2_and_publication_date: adiciona fallback para
  xml_with_pre.get_complete_publication_date() quando
  article_publication_date não está disponível/é inválida.
- Package.prepare_sps_package / prepare_to_publish: adicionam o
  parâmetro force_update, permitindo forçar a atualização do SPSPkg
  mesmo quando já registrado e válido no Core; ajustado o filtro de
  pdf_langs em renditions removendo a checagem redundante contra
  xml_with_pre.filenames.
- PidReservation.get: passa a aceitar name_list, permitindo buscar por
  múltiplas variações de pkg_name (pkg_name__in).
- PidV2Generator.generate: usa xml_with_pre.pkg_name_variations (com
  fallback para sps_pkg_name + deprecated_sps_pkg_name_list) ao
  consultar PidReservation, evitando falha na resolução de pid_v2
  quando o nome do pacote mudou; remove logs de depuração
  (logging.info) intermediários do fluxo.
@robertatakenaka robertatakenaka changed the title Rc fix pdf path Corrige a obtenção dos pdfs do pacote do Upload v3.x Aug 3, 2026
@robertatakenaka
robertatakenaka merged commit af6228e into scieloorg:rc Aug 4, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants