[robertatakenaka]

O que esse PR faz?

Garante que o registro de um XML no pid_provider grave, de forma consistente, o pid v2 e a versão do XML da coleção de origem, ou falhe sem deixar registro parcial. Também passa a guardar o nome do pacote SPS em cada registro de coleção (CollectionPidV2.sps_pkg_name).

Problemas resolvidos:

• uma falha durante o registro podia deixar o pid v2 da coleção principal gravado sem o CollectionPidV2 correspondente; _save agora executa dentro de transaction.atomic
• um XML cuja coleção de origem (custom-meta) não está entre as coleções do periódico era aceito sem que o pid v2 e a versão daquela coleção fossem registrados; agora o registro é rejeitado com XMLCollectionNotFoundErrorToGetPidProviderXMLError
• na falta do acrônimo do periódico na coleção, o registro da coleção falhava; agora usa o acrônimo do XML normalizado
• OtherPid não era criado quando faltava a coleção principal (sem current_version), e o erro era descartado silenciosamente; version passa a ser opcional
• os OtherPid passam a ser associados à versão da coleção do XML e, na falta dela, à da coleção principal
• o erro de verificação de registro em BasePidProvider era descartado (return com valor em um gerador); agora é entregue com yield
• FixPidV2.__str__ e autocomplete_label falhavam quando pid_provider_xml estava ausente

Funcionalidades adicionadas:

• campo CollectionPidV2.sps_pkg_name, indexado e exibido somente para leitura no admin, preenchido a partir de current_version.xml_with_pre ao criar ou atualizar o registro
• task task_complete_collection_pid_v2_sps_pkg_name, que preenche os registros existentes em lotes processados por subtarefas, e script pid_provider/scripts/complete_collection_pid_v2_sps_pkg_name.py para dispará-la
• CollectionPidV2.get_or_create, que trata a criação concorrente via IntegrityError

Onde a revisão poderia começar?

pid_provider/models.py, em PidProviderXML.register (nova validação da coleção do XML e transaction.atomic em torno de _save). Em seguida, a classe CollectionPidV2 (campo sps_pkg_name e métodos de preenchimento) e pid_provider/tasks.py.

Como este poderia ser testado manualmente?

1. Aplicar a migração: python manage.py migrate pid_provider
2. Executar os testes: python manage.py test pid_provider article
3. Registrar um XML de um periódico presente em mais de uma coleção e verificar, no admin, que cada CollectionPidV2 exibe o sps_pkg_name da sua versão do XML
4. Registrar um XML cuja coleção de origem (custom-meta) não é uma das coleções do periódico e verificar que a resposta é de erro, com XMLCollectionNotFoundErrorToGetPidProviderXMLError, e que nenhum dado do documento foi alterado
5. Executar python manage.py runscript complete_collection_pid_v2_sps_pkg_name e verificar que os CollectionPidV2 existentes com current_version tiveram sps_pkg_name preenchido

Algum cenário de contexto que queira dar?

Com a arquitetura de pid v2 por coleção, um mesmo documento pode ser registrado a partir de XMLs de coleções diferentes, cada um com seu pid v2 e sua versão. O PidProviderXML guarda o pid v2 e a versão da coleção principal, e cada coleção tem seu CollectionPidV2. Os casos corrigidos aqui deixavam esses dois níveis inconsistentes: o documento identificado, mas sem o registro da coleção de origem.

get_xml_collections retorna todas as coleções do periódico, sem filtrar pela coleção de origem do XML. É isso que permite a register detectar quando a coleção do XML não é uma das coleções do periódico.

O preenchimento de sps_pkg_name nos registros existentes exige ler o XML de cada versão, por isso é feito em lotes por subtarefas, para respeitar o limite de tempo das tarefas do celery. Após a implantação, é necessário executar o script uma vez.

Screenshots

N/A

Quais são os tickets relevantes?

complementar a #1483

Referências

N/A

---

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

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