Melhora fluxo de criacao e atualizacao de artigo

[robertatakenaka]

O que esse PR faz?

Reduz a dependência dos modelos ArticleEvent e XMLEvent, migrando o registro de erros e progresso do pipeline de artigos para UnexpectedEvent (mais genérico) e para o campo article.errors, já existente no modelo Article:

• Em article/tasks.py (task_export_article_to_articlemeta e task_process_article_pipeline), introduz variáveis de rastreamento (item / unexpected_event_item) atualizadas a cada etapa do fluxo, e padroniza as chamadas a UnexpectedEvent.create(action=..., item=...), enriquecendo detail com mais contexto (collection_acron_list, source_date, auto_solve_pid_conflict, version).
• Em article/sources/xmlsps.py (load_article):
  • Remove o uso de ArticleEvent (article.add_event(...) / event.finish(...)), eliminando article.events.all().delete() e as ramificações if event: ....
  • Introduz a função finish(article, errors, messages), que grava errors/messages diretamente em article.errors e decide entre mark_as_completed() e save().
  • Substitui logging.info(...) por uma lista messages, persistida via finish(...).
  • Corrige perda de exceção no fluxo de erro (add_error(errors, "load_article", e) antes de finish(...)).
  • Simplifica o tratamento de pp_xml.xml_with_pre e passa a reaproveitar o Article já vinculado ao pp_xml, evitando duplicação.
  • Remove imports não mais usados, incluindo PPXML_STATUS_* e PidProviderXML.
• Em article/models.py (Article.check_availability), remove totalmente a dependência do event (ArticleEvent), chamando UnexpectedEvent.create(action=..., item=..., detail={"traceback": ...}) incondicionalmente.

Resultado líquido: três pontos do pipeline de artigos que antes dependiam de ArticleEvent agora usam apenas UnexpectedEvent ou article.errors, aproximando o código do objetivo de descontinuar ArticleEvent/XMLEvent como modelos separados.

Onde a revisão poderia começar?

article/sources/xmlsps.py, função load_article e a nova função finish — é onde a remoção de ArticleEvent é mais visível. Em seguida, article/models.py, no bloco except de check_availability. Por fim, article/tasks.py, revisando as novas chamadas a UnexpectedEvent.create(...).

Como este poderia ser testado manualmente?

1. Rodar task_process_article_pipeline com um pp_xml_id válido e verificar que nenhum ArticleEvent é criado, que article.errors é preenchido com messages (e errors, se houver falha), e que reprocessar o mesmo pp_xml reaproveita o Article existente.
2. Forçar um erro proposital em load_article (ex.: journal inexistente) e confirmar que nenhum ArticleEvent é criado e que a exceção é registrada em article.errors antes do raise.
3. Rodar Article.check_availability(force_update=True) provocando uma exceção e verificar que nenhum event (ArticleEvent) é criado e que UnexpectedEvent.create(...) é chamado com action, item e detail={"traceback": ...} corretamente.
4. Buscar no código (grep -r "add_event\|ArticleEvent\|XMLEvent") para confirmar que os pontos alterados neste PR não deixaram nenhuma referência residual.

Algum cenário de contexto que queira dar?

Esta mudança é parte de um esforço maior para descontinuar os modelos ArticleEvent e XMLEvent, substituindo-os por UnexpectedEvent e por campos já existentes nas próprias entidades (como article.errors). O objetivo de longo prazo é remover esses modelos do banco assim que todos os pontos de uso forem migrados — este PR cobre a parte de article/tasks.py, article/sources/xmlsps.py e article/models.py.

Screenshots

Não aplicável — mudança apenas em código de backend/pipeline, sem interface visual.

Quais são os tickets relevantes?

#1454

Referências

• article/tasks.py
• article/sources/xmlsps.py
• article/models.py

---

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):
  (preencher conforme resultado do pipeline no CI antes de abrir o 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)