Evita levantar pid provider xml pid v3 conflict error devido a registro equivocado de other_pid

[robertatakenaka]

O que esse PR faz?

Simplifica a consulta de registros por PID v3 na model PidProviderXML. A busca que antes verificava tanto o campo v3 direto quanto a relação other_pid__pid_in_xml via condição OR (|) foi ajustada para filtrar unicamente pelo atributo v3=xml_pid_v3.

Onde a revisão poderia começar?

pid_provider/models.py — método get_record_by_pid_v3 na classe PidProviderXML.

Como este poderia ser testado manualmente?

1. Executar os testes unitários do módulo pid_provider:

   pytest pid_provider/tests/

2. Garantir que as buscas por registros utilizando PID v3 através de PidProviderXML.get_record_by_pid_v3(...) retornem o registro esperado quando o PID v3 existe e lancem DoesNotExist quando o PID não for encontrado no campo principal.

Algum cenário de contexto que queira dar?

A verificação secundária através de other_pid__pid_in_xml tornou-se desnecessária / redundante para a lógica de busca do get_record_by_pid_v3. A remoção da condição de OR melhora o desempenho da query e simplifica a manutenção da consulta no ORM do Django.

Screenshots

N/A (alteração exclusiva de regra de negócio/backend).

Quais são os tickets relevantes?

N/A

Referências

N/A

---

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): Refatoração pontual de código Python interno/ORM sem alteração de dependências ou exposição de novos componentes.

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)

[patymori]

Resultado dos testes automatizados: