Repository navigation
WIP Fix issue am - #1496
Draft
robertatakenaka wants to merge 19 commits into
Draft
WIP Fix issue am#1496robertatakenaka wants to merge 19 commits into
robertatakenaka wants to merge 19 commits into
Conversation
Adiciona UniqueConstraint (collection, pid) em AMJournal (unique_amjournal_collection_pid).
Migração que cria a UniqueConstraint unique_amjournal_collection_pid (collection, pid) em AMJournal.
create_or_update_scielo_journal aceita uma instância de Collection e só chama get_collection quando recebe um identificador.
…cleMeta A coleção do SciELOJournal era obtida dos dados do periódico, que podem trazer o code e não o acron3 da coleção. Com isso, o SciELOJournal podia ficar em coleção diferente da do AMJournal e do AMIssue. Detalhes de implementação: - _register_journal_data passa journal_am.collection para create_or_update_scielo_journal
TestJournalLoadedFromArticleMetaInCollections verifica que são gerados um único Journal e um AMJournal e um SciELOJournal por coleção. O teste cobre coletas repetidas e coleção com code diferente de acron3.
O issue_pid pode divergir entre coleções, pois o issn_scielo e a ordem atribuída manualmente no legado podem ser diferentes. O issue_pid passa a ser obtido do AMIssue de cada coleção: - os pids estabelecidos são preservados - pids novos são gerados apenas nas coleções faltantes - coletas paralelas do mesmo fascículo em coleções diferentes deixam de criar Issues distintos O issue_pid_suffix passa a ser apenas a ordem calculada pela regra, usada para gerar pids novos. Detalhes de implementação: - AMIssue: UniqueConstraint (collection, pid) - create_legacy_keys: cria AMIssue só nas coleções sem chave; o pid é issn_scielo + ano + issue_pid_suffix, avançando para a próxima ordem livre quando já usado na coleção; os erros são registrados por coleção em UnexpectedEvent - novo get_issue_pid(collection, create=True): retorna o pid da coleção (Collection ou acron3), priorizando o migrado (com url), e cria o pid se ausente - get: exige journal e year; volume, number e supplement ausentes filtram por ausência (None ou ""), em vez de serem ignorados; os campos calculados são gravados via update, sem disparar save - create / get_or_create: o parâmetro migrated substitui issue_pid_suffix, que deixa de ser recebido - get_or_create: transaction.atomic com select_for_update no Journal, para serializar a criação; a lógica foi movida para _get_or_create - add_am_issue: remove o pid gerado na mesma coleção quando chega o pid estabelecido; se o AMIssue pertencia a outro fascículo, gera um novo pid para esse fascículo; status "done" em vez de "completed" - save: não gera pids para Issue migrado (_migrated)
Migração que cria a UniqueConstraint unique_amissue_collection_pid (collection, pid) em AMIssue.
extract_data_from_harvested_data não retorna mais issue_pid_suffix, que era copiado de pid[-4:]. Esse valor passa a ser calculado pela regra, e o pid estabelecido fica no AMIssue.
…leMeta create_issue_from_am_issue cria o Issue com migrated=True e deixa de passar issue_pid_suffix. Assim nenhum pid é gerado antes de o pid do AMIssue ser associado por add_am_issue.
_format_code usa Issue.get_issue_pid com a coleção do SciELOJournal, em vez de montar issn_scielo + ano + issue_pid_suffix.
Somente comentários e docstring; sem mudança de comportamento.
Fascículos criados antes da existência do AMIssue não têm issue_pid por
coleção. Alguns também têm issue_pid_suffix copiado de um pid manual. A
nova rotina associa os pids migrados, recalcula a ordem e gera os pids
faltantes, nessa sequência, para que os pids migrados prevaleçam sobre
os gerados.
Detalhes de implementação:
- novo migrate_issue_legacy_keys, filtrável por coleção, journal pid e
ano, com três etapas:
1. associa AMIssue migrados sem new_record via
create_issue_from_am_issue
2. recalcula issue_pid_suffix via update, sem save, para não gerar
pids antes da etapa 3
3. executa create_legacy_keys nos Issues com menos coleções com AMIssue
do que coleções do periódico (todos, com force_update)
- retorna estatísticas; erros por Issue são registrados em UnexpectedEvent
A limpeza de AMIssue órfãos removia também os pids gerados pelo sistema, que não têm data nem url. A correção das chaves legadas de fascículos passa a estar disponível como tarefa. Detalhes de implementação: - task_update_issues_from_amissue: a limpeza exclui os AMIssue com new_record - nova task_migrate_issue_legacy_keys, que chama controller.migrate_issue_legacy_keys e registra falhas em UnexpectedEvent
Router da API v2 (namespace api_v2), incluído em config/urls.py sob api/v2/, com o endpoint de issue que expõe o issue_pid por coleção.
Inclui a rota api/v2/ (config.api_router_v2) fora de i18n_patterns, sem prefixo de idioma, após as rotas mais específicas de api/v2/pid/ e api/v2/auth/.
O pid v2 pode divergir entre coleções. O core não gera nem deriva esse pid, pois isso é responsabilidade do scms-upload. A chave legada passa a vir apenas do pid v2 registrado no pid provider para cada coleção. Uma coleção sem esse registro fica sem AMArticle. Detalhes de implementação: - create_legacy_keys percorre pp_xml.collection_pids_v2, em vez de derivar o pid a partir das chaves legadas da issue - remove AMArticle não migrado (sem data/url) com pid diferente do XML da coleção - reutiliza o AMArticle existente: associa se estiver sem new_record e não cria duplicado se pertencer a outro artigo - tolera artigo sem issue ou sem pp_xml; remove o atalho por contagem de coleções
Cobre a criação de AMArticle a partir do CollectionPidV2 registrado no pid provider, sem geração nem derivação do pid v2 no core.
Cobre: - geração de pid por coleção, com a próxima ordem livre - fascículos migrados sem pids gerados - correção de issue_pid_suffix por migrate_issue_legacy_keys - substituição do pid gerado pelo pid estabelecido - get_issue_pid e exportação para o ArticleMeta por coleção - API v1 x v2 (issue_pid por coleção, rota sem prefixo de idioma) - carga do mesmo fascículo do ArticleMeta em várias coleções, com um Issue único e AMIssue único por (collection, pid)
robertatakenaka
marked this pull request as draft
November 6, 2026 13:24
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O que esse PR faz?
Corrige o tratamento do issue_pid e das chaves legadas (AMJournal, AMIssue, AMArticle) quando o periódico é publicado em mais de uma coleção e o pid diverge entre elas.
Issue.get_issue_pid). Os pids estabelecidos no legado são preservados, e pids novos são gerados apenas nas coleções faltantes, usando a próxima ordem livre quando há colisão.migrated=True) não geram pids na criação. O pid do legado é associado em seguida. Se esse pid já tinha sido gerado para outro fascículo, o outro fascículo recebe um pid novo.(collection, pid)em AMIssue e AMJournal. Duplicados existentes são consolidados (BaseLegacyRecord.deduplicate), e a criação concorrente é tratada como atualização.CollectionPidV2). O core não gera nem deriva o pid v2.new_record).migrate_issue_legacy_keys/task_migrate_issue_legacy_keys, que corrige fascículos criados antes do AMIssue.api/v2/, sem prefixo de idioma, com o endpoint de issue que expõe oissue_pidpor coleção.Onde a revisão poderia começar?
core/models.py:BaseLegacyRecord(get,deduplicate,create,create_or_update)issue/models.py:Issue.create_legacy_keys,Issue.get_issue_pid,Issue.get,Issue.get_or_create,Issue.add_am_issue,Issue.saveissue/controller.py:migrate_issue_legacy_keysarticle/models.py:Article.create_legacy_keysissue/tests.py,journal/tests.pyearticle/tests/test_legacy_keys.pyComo este poderia ser testado manualmente?
(collection, pid)em AMIssue e AMJournal. As novas constraints fazem omigratefalhar se houver duplicados, então eles devem ser consolidados antes.python manage.py migrate.python manage.py test issue journal article.sclepsi).task_migrate_issue_legacy_keys, filtrando por esse periódico (journal_pid_list) e, opcionalmente, por ano (publication_year). Confira as estatísticas no log./api/v2/issue/?collection=<acron3>e confira seissue_pidcorresponde ao pid da coleção e selegacy_issuetraz os pids de todas as coleções.codecorresponde ao issue_pid de cada coleção.Algum cenário de contexto que queira dar?
No legado, o issue_pid de um mesmo fascículo pode ser diferente em cada coleção, por exemplo
0103-656420240005emscle1678-517720240002empsi. Isso ocorre porque o issn_scielo difere entre as coleções e porque a ordem do fascículo foi, muitas vezes, atribuída manualmente.O core gerava o pid a partir de um único
issue_pid_suffix, copiado do pid de uma das coleções. Isso produzia pids errados, ou já usados por outro fascículo, nas demais coleções.Pelas mesmas razões, o pid v2 do artigo não é gerado nem derivado no core. A geração do pid v2 de artigos novos é responsabilidade do scms-upload, e o core usa o que foi registrado no pid provider para cada coleção.
Fascículos já existentes devem ser corrigidos com
task_migrate_issue_legacy_keysapós a atualização.Screenshots
N/A
Quais são os tickets relevantes?
#1495
Referências
N/A
Segurança da informação (NSI.04)
Este PR manipula dados sensíveis ou pessoais (LGPD)?
Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?
Este PR introduz, atualiza ou remove dependências de terceiros?
Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?
Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?
Este PR expõe novos endpoints, telas ou serviços?
/api/v2/issue/, somente leitura, com a mesma autenticação e as mesmas permissões da API v1, servido sob HTTPS como as demais rotas da aplicação.Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?