Traz para o **core** as atualizações já implementadas no **upload** para o app `pid_provider` by robertatakenaka · Pull Request #1449 · scieloorg/core

robertatakenaka · 2026-07-20T19:50:03Z

O que esse PR faz?

Este PR traz para o core as atualizações já implementadas no upload (1026) para o app pid_provider, aplicando um conjunto de refatorações no fluxo de correspondência/registro de XML e adicionando um modelo de auditoria por documento. Principais mudanças:

Nova estratégia de correspondência (matching) de XML já registrados: get_records/get_record/best_matches (baseados em score aditivo por campo) são substituídos por select_records (generator com estratégias em estágios: ids → journal-issue-article → journal-article) e select_record/get_best_match, que comparam candidatos usando funções de similaridade textual (compare, compare_items, compare_lists em query_params.py), retornando percentual_score em vez de score bruto.
QueryBuilderPidProviderXML refatorado: centraliza o acesso via adapter_data, compare_data e xml_with_pre_data, e ganha validate_input_data() e article_location_params.
Nova auditoria por documento: modelo PidProviderXMLRegistration, que grava (via finally em register()) o resultado de cada tentativa (created, updated, skipped, forbidden, conflict, unmatched, bad_request, error), com detail em JSON. Este modelo substitui XMLEvent, que é removido junto com panels_event e o método add_event.
Migração 0017_pidproviderxmlregistration_remove_xmlevent_creator_and_more.py, que:
- Cria o modelo PidProviderXMLRegistration (com FKs creator, updated_by, pid_provider_xml e índices pid_provide_pkg_nam_2db0b2_idx, pid_provide_event_s_3c9ae7_idx, pid_provide_created_94fb08_idx, pid_provide_pid_pro_c9fb0e_idx);
- Remove os campos creator, ppxml e updated_by de XMLEvent e, em seguida, exclui o modelo XMLEvent;
- Adiciona readable_data (JSONField) em PidProviderXML;
- Adiciona detail (JSONField) e is_public (BooleanField) em XMLURL, altera o campo status (agora com choices) e cria o índice pid_provide_is_public_idx.
PidProviderXML.register() reescrito: usa try/except/finally para sempre registrar o evento de auditoria, inclusive quando is_updated sinaliza que o registro deve ser pulado (novo fluxo via exceção SkipSavePidProviderXML, em vez de retornar registered.data silenciosamente).
Correções de bugs:
- merge_records: other_pid.current_version (atributo inexistente em OtherPid) corrigido para other_pid.version.
- mark_items_as_invalid: o valor calculado de invalidade agora é de fato persistido via bulk_update.
- add_collections (extraído de _save): usa FieldError para detectar se a coleção usa scielojournal ou journalproc, tratando a divergência estrutural entre upload e core.
Performance: PidProviderXMLManager customizado aplica select_related("current_version") em todo PidProviderXML.objects; uso de Prefetch(..., to_attr=...) em merge_records para não quebrar o cache do prefetch ao filtrar.
XMLURL: novo classmethod record() para centralizar a gravação de tentativas de URL com falha, usando os novos campos detail e is_public.
Wagtail admin: novos XMLURLViewSet e PidProviderXMLRegistrationViewSet registrados no PidProviderViewSetGroup.
Dependência: packtools atualizado de 4.15.0 para 4.16.8 (necessário para os novos métodos usados em models.py, como get_article_data, get_complete_publication_date, deprecated_sps_pkg_name_list, get_body_fragment).

Onde a revisão poderia começar?

pid_provider/models.py, pelo método PidProviderXML.register(). Em seguida, select_records/select_record/get_best_match no mesmo arquivo e compare/compare_items em pid_provider/query_params.py. Por fim, conferir a migração 0017_pidproviderxmlregistration_remove_xmlevent_creator_and_more.py, especialmente a remoção do modelo XMLEvent (dado que remove uma tabela existente).

Como este poderia ser testado manualmente?

Subir o ambiente local com o banco migrado: python manage.py migrate pid_provider.
Confirmar que a migração 0017 roda sem erros e que a tabela de XMLEvent deixa de existir (verificar se não há dependências externas quebradas por essa remoção, ex.: relatórios ou dashboards que ainda consultem XMLEvent).
Enviar um XML novo (sem PID registrado) e verificar:
- Criação de um novo PidProviderXML;
- Criação de um PidProviderXMLRegistration com event_status="created".
Reenviar o mesmo XML sem alterações e verificar que o processo é ignorado (SkipSavePidProviderXML).
Enviar uma variação do XML do mesmo artigo (ex.: pequena alteração de título/autores) e conferir que select_record/get_best_match reconhece o mesmo documento e atualiza (event_status="updated").
Forçar um conflito (dois XMLs com PID v3 igual mas dados de artigo divergentes) e verificar o event_status="conflict"/unmatched.
Acessar o Wagtail admin e conferir as novas listagens "XML URLs" e "PID Registration Events", validando filtros (status, is_public, event_status).
Rodar a suíte de testes do app pid_provider (python manage.py test pid_provider).

Algum cenário de contexto que queira dar?

O app pid_provider é compartilhado entre os sistemas upload e core. As mudanças deste PR já foram desenvolvidas e validadas no upload e este PR traz essas atualizações para o core, mantendo os dois projetos alinhados. A migração inclui a remoção definitiva do modelo XMLEvent (substituído por PidProviderXMLRegistration), portanto é importante avaliar se há dados históricos relevantes em XMLEvent antes de aplicar em produção. A atualização do packtools para 4.16.8 é pré-requisito funcional das mudanças em models.py.

Screenshots

Não aplicável (mudanças de backend/modelo de dados).

Quais são os tickets relevantes?

scieloorg/scms-upload#1026

Referências

Documentação interna do fluxo pid_provider (registro e correspondência de XML).
Padrão de auditoria já adotado em proc/package (resultados estruturados em dict).
Changelog do packtools entre 4.15.0 e 4.16.8.

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

Este PR manipula dados sensíveis ou pessoais (LGPD)?

Sim
Não — readable_data e o detail de auditoria armazenam metadados bibliográficos já presentes no XML público do documento; nenhum dado pessoal sensível é tratado.

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

Sim
Não

Este PR introduz, atualiza ou remove dependências de terceiros?

Sim
Não — o packtools é biblioteca própria da SciELO (scieloorg/packtools), não uma dependência de terceiros; trata-se apenas de bump de versão interno necessário para os novos métodos usados nesta refatoração.

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

Sim — link do job:
Não aplicável a este PR — nenhuma dependência de terceiros foi adicionada ou alterada; aguardando execução do pipeline padrão do PR.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

Sim
Não — todo o acesso a dados usa ORM do Django (Q, filter, Prefetch), sem SQL raw.

Este PR expõe novos endpoints, telas ou serviços?

Sim — novas telas administrativas no Wagtail (XMLURLViewSet, PidProviderXMLRegistrationViewSet), restritas à área administrativa (login/staff), seguindo as políticas de permissão já aplicadas aos demais snippets do app.
Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

Não, nenhum segredo foi commitado
Sim

Boa lembrança — ajusta a leitura de risco. Segue a correção:

Ajustes no texto do PR

No corpo do PR, troque a frase sobre o packtools por:

Dependência interna SciELO: packtools (biblioteca própria da organização, mantida em scieloorg/packtools) atualizado de 4.15.0 para 4.16.8 — necessário para os novos métodos usados em models.py (get_article_data, get_complete_publication_date, deprecated_sps_pkg_name_list, get_body_fragment).

E no "Algum cenário de contexto que queira dar?", ajuste a última frase para:

A atualização do packtools para 4.16.8 é pré-requisito funcional das mudanças em models.py — trata-se de biblioteca própria da SciELO (não é dependência de terceiros), então o risco de supply chain é o mesmo já assumido para o restante do ecossistema scieloorg.

Na seção de Segurança da Informação (NSI.04), corrija:

Este PR introduz, atualiza ou remove dependências de terceiros?

Sim
Não — o packtools é biblioteca própria da SciELO (scieloorg/packtools), não uma dependência de terceiros; trata-se apenas de bump de versão interno necessário para os novos métodos usados nesta refatoração.

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

Sim — link do job:
Não aplicável a este PR — nenhuma dependência de terceiros foi adicionada ou alterada; aguardando execução do pipeline padrão do PR.

Propósito: disponibilizar os novos métodos do packtools utilizados pelas refatorações do pid_provider (get_article_data, get_complete_publication_date, deprecated_sps_pkg_name_list, get_body_fragment). Solução técnica: bump de versão fixado via git+https no requirements/base.txt.

Propósito: padronizar os valores possíveis do campo status do modelo XMLURL, substituindo texto livre por opções controladas. Solução técnica: cria XMLURL_STATUS_SUCCESS, XMLURL_STATUS_XML_FETCH_FAILED, XMLURL_STATUS_PID_PROVIDER_XML_FAILED e a tupla XMLURL_STATUS.

Propósito: permitir que is_updated() sinalize, via exceção, que o registro deve ser ignorado (equal ou já atualizado), em vez de retornar dados silenciosamente. Solução técnica: cria a classe SkipSavePidProviderXML(Exception).

…omparação por similaridade Propósito: substituir o cálculo de score aditivo por campo por comparação percentual baseada em similaridade textual, e simplificar o builder de queries centralizando o acesso aos dados do adaptador. Solução técnica: adiciona compare/compare_items/compare_lists usando how_similar; QueryBuilderPidProviderXML passa a usar adapter_data, compare_data e xml_with_pre_data como fonte única, com validate_input_data() e article_location_params novos; remove as antigas cached_property espelhando atributos do xml_adapter.

…e XML e cria auditoria por documento Propósito: tornar o processo de identificação de documentos já registrados mais preciso (comparação por similaridade em estágios) e garantir rastreabilidade de toda tentativa de registro (sucesso, erro, conflito, skip), substituindo o modelo de eventos XMLEvent. Solução técnica: - get_records/get_record/best_matches substituídos por select_records (generator em estágios: ids, journal-issue-article, journal-article), select_record e get_best_match, usando percentual_score. - PidProviderXML.register() reescrito com try/except/finally, sempre gravando o evento via PidProviderXMLRegistration.record(). - is_updated() passa a levantar SkipSavePidProviderXML em vez de retornar registered.data. - Novo PidProviderXMLManager aplicando select_related('current_version') por padrão. - Novo campo readable_data em PidProviderXML. - add_collections extraído de _save(), com fallback via FieldError entre scielojournal e journalproc (compatibilidade upload/core). - Corrige bug em merge_records (other_pid.version, não other_pid.current_version) e em mark_items_as_invalid (persiste o status calculado via bulk_update). - XMLURL ganha os campos detail e is_public e o classmethod record(). - Remove modelo XMLEvent e o método add_event().

…o de XMLEvent Propósito: aplicar no banco de dados as mudanças de modelo introduzidas na refatoração do pid_provider. Solução técnica: cria o modelo PidProviderXMLRegistration com seus índices (pid_provide_pkg_nam_2db0b2_idx, pid_provide_event_s_3c9ae7_idx, pid_provide_created_94fb08_idx, pid_provide_pid_pro_c9fb0e_idx); remove os campos creator, ppxml e updated_by de XMLEvent e em seguida exclui o modelo XMLEvent; adiciona readable_data em PidProviderXML; adiciona detail e is_public em XMLURL, altera o campo status (com choices) e cria o índice pid_provide_is_public_idx.

…onViewSet no Wagtail admin Propósito: permitir consulta, pela interface administrativa, das URLs com falha de processamento (XMLURL) e dos eventos de auditoria de registro de XML (PidProviderXMLRegistration). Solução técnica: cria XMLURLViewSet e PidProviderXMLRegistrationViewSet (list_display, list_filter, search_fields e select_related no get_queryset) e os inclui em PidProviderViewSetGroup.

patymori · 2026-07-20T22:03:35Z

@robertatakenaka o pytest do CI está falhando porque está usando o docker-compose ao invés de docker compose

patymori · 2026-07-20T22:38:15Z

 from wagtailautocomplete.edit_handlers import AutocompletePanel

 from collection.models import Collection
+from core.widgets import ReadOnlyPrettyJSONWidget


Ocorreu o seguinte erro:

Traceback (most recent call last): File "/app/manage.py", line 31, in <module> execute_from_command_line(sys.argv) File "/usr/local/lib/python3.11/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.11/site-packages/django/core/management/__init__.py", line 416, in execute django.setup() File "/usr/local/lib/python3.11/site-packages/django/__init__.py", line 24, in setup apps.populate(settings.INSTALLED_APPS) File "/usr/local/lib/python3.11/site-packages/django/apps/registry.py", line 116, in populate app_config.import_models() File "/usr/local/lib/python3.11/site-packages/django/apps/config.py", line 269, in import_models self.models_module = import_module(models_module_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<frozen importlib._bootstrap>", line 1204, in _gcd_import File "<frozen importlib._bootstrap>", line 1176, in _find_and_load File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 690, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 940, in exec_module File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed File "/app/article/models.py", line 47, in <module> from pid_provider.models import PidProviderXML File "/app/pid_provider/models.py", line 24, in <module> from core.widgets import ReadOnlyPrettyJSONWidget ModuleNotFoundError: No module named 'core.widgets'

patymori

Verificar os impactos da remoção do método PidProviderXML.add_event()
Remoção de testes unitários do módulo invalida um dos pontos dos testes manuais sugeridos no PR
Sugestão: aumentar a cobertura de testes unitários no módulo article.

patymori · 2026-07-21T13:45:20Z

            return True
        return False
-
-    def add_event(self, name, proc_status, detail=None, errors=None, exceptions=None):


@robertatakenaka encontrei alguns lugares que referenciam este método:

https://github.com/scieloorg/core/blob/main/article/sources/xmlsps.py#L129

https://github.com/scieloorg/core/blob/main/article/sources/xmlsps.py#L265

…erXML Propósito: Reverter a remoção do model XMLEvent feita em refatoração anterior — o rastreio de eventos por documento (registration attempts, validation errors, etc.) via XMLEvent ainda é necessário e não deve ser substituído pelo novo PidProviderXMLRegistration, que serve a um propósito complementar (auditoria agregada de register()), não ao histórico de eventos por instância de PidProviderXML. Solução técnica: Reintroduzido o import de BaseEvent em 'from tracker.models import BaseEvent, UnexpectedEvent'. Restaurado o método PidProviderXML.add_event(name, proc_status, detail=None, errors=None, exceptions=None), que atualiza proc_status, salva a instância e delega o registro do evento a XMLEvent.register(). Restaurado o model XMLEvent(BaseEvent, CommonControlField), com o campo ppxml (ParentalKey para PidProviderXML, related_name='events') e o classmethod register(), que cria a instância, marca completed conforme presença de errors/exceptions e delega a finalização a BaseEvent.finish().

Propósito: Consistência com a reversão feita em models.py — como o model XMLEvent voltou a existir no código, a migration 0017 (que removia seus campos creator/ppxml/updated_by e por fim o próprio model via DeleteModel) deixou de refletir o estado real dos models e precisa ser descartada. Solução técnica: Excluído o arquivo pid_provider/migrations/0017_pidproviderxmlregistration_remove_xmlevent_creator_and_more.py. A criação de PidProviderXMLRegistration e os demais campos que essa migration também introduzia (readable_data, XMLURL.detail/is_public, choices de XMLURL.status, índices) precisam ser recriados em uma nova migration, desta vez sem a remoção de XMLEvent — rodar 'python manage.py makemigrations pid_provider' para gerá-la a partir do estado atual dos models.

robertatakenaka · 2026-07-21T18:18:39Z

@patymori o foco principal deste PR é para garantir a atribuição / recuperação do pid v3 que não deve ter relacionamento diretamente com o Article, pois se houver o PR vai ficar muito extenso.

patymori

Ocorreu um outro erro:

 /usr/local/lib/python3.11/site-packages/django/db/backends/utils.py:98: RuntimeWarning: Accessing the database during app initialization is discouraged. To fix this warning, avoid executing queries in AppConfig.ready() or when your app modules are imported.
   warnings.warn(self.APPS_NOT_READY_WARNING_MSG, category=RuntimeWarning)
 System check identified some issues:
 
 WARNINGS:
 ?: (urls.W005) URL namespace 'pid_provider' isn't unique. You may not be able to reverse all URLs in this namespace
 ?: (wagtailadmin.W003) The WAGTAILADMIN_BASE_URL setting is not defined
 	HINT: This should be the base URL used to access the Wagtail admin site. Without this, admin URLs outside of the admin (e.g. notification emails and the user bar) will not display correctly.
 ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: settings.ACCOUNT_LOGIN_METHODS = {'username'}
 ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use: settings.ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*']
 pid_provider.FixPidV2.pid_provider_xml: (fields.W342) Setting unique=True on a ForeignKey has the same effect as using a OneToOneField.
 	HINT: ForeignKey(unique=True) is usually better served by a OneToOneField.
 Operations to perform:
   Apply all migrations: account, admin, altmetric, article, auth, book, collection, contenttypes, core, core_settings, django_celery_beat, django_celery_results, doi, doi_manager, editorialboard, files_storage, home, institution, issue, journal, journalpage, location, organization, otp_totp, pid_provider, reference, report, researcher, sessions, silk, simple_translation, sites, socialaccount, taggit, thematic_areas, tracker, users, vocabulary, wagtail_2fa, wagtail_localize, wagtailadmin, wagtailcore, wagtaildocs, wagtailembeds, wagtailforms, wagtailimages, wagtailredirects, wagtailsearch, wagtailsearchpromotions, wagtailusers, xml_validation
 Running migrations:
 Traceback (most recent call last):
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 103, in _execute
     return self.cursor.execute(sql)
            ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django_prometheus/db/common.py", line 69, in execute
     return super().execute(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 psycopg2.errors.DuplicateTable: relation "pid_provider_pidproviderxmlregistration" already exists
 
 
 The above exception was the direct cause of the following exception:
 
 Traceback (most recent call last):
   File "/app/manage.py", line 31, in <module>
     execute_from_command_line(sys.argv)
   File "/usr/local/lib/python3.11/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
     utility.execute()
   File "/usr/local/lib/python3.11/site-packages/django/core/management/__init__.py", line 436, in execute
     self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python3.11/site-packages/django/core/management/base.py", line 416, in run_from_argv
     self.execute(*args, **cmd_options)
   File "/usr/local/lib/python3.11/site-packages/django/core/management/base.py", line 460, in execute
     output = self.handle(*args, **options)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/core/management/base.py", line 107, in wrapper
     res = handle_func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/core/management/commands/migrate.py", line 353, in handle
     post_migrate_state = executor.migrate(
                          ^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/migrations/executor.py", line 135, in migrate
     state = self._migrate_all_forwards(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/migrations/executor.py", line 167, in _migrate_all_forwards
     state = self.apply_migration(
             ^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/migrations/executor.py", line 255, in apply_migration
     state = migration.apply(state, schema_editor)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/migrations/migration.py", line 132, in apply
     operation.database_forwards(
   File "/usr/local/lib/python3.11/site-packages/django/db/migrations/operations/models.py", line 97, in database_forwards
     schema_editor.create_model(model)
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/schema.py", line 512, in create_model
     self.execute(sql, params or None)
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/postgresql/schema.py", line 45, in execute
     return super().execute(sql, params)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/base/schema.py", line 204, in execute
     cursor.execute(sql, params)
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 122, in execute
     return super().execute(sql, params)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 79, in execute
     return self._execute_with_wrappers(
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 92, in _execute_with_wrappers
     return executor(sql, params, many, context)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 100, in _execute
     with self.db.wrap_database_errors:
   File "/usr/local/lib/python3.11/site-packages/django/db/utils.py", line 91, in __exit__
     raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/usr/local/lib/python3.11/site-packages/django/db/backends/utils.py", line 103, in _execute
     return self.cursor.execute(sql)
            ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/local/lib/python3.11/site-packages/django_prometheus/db/common.py", line 69, in execute
     return super().execute(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 django.db.utils.ProgrammingError: relation "pid_provider_pidproviderxmlregistration" already exists

robertatakenaka · 2026-07-22T14:11:39Z

@patymori execute:

make django_bash

python manage.py migrate pid_provider 0017 --fake
python manage.py migrate

robertatakenaka added 8 commits July 20, 2026 15:42

Apaga testes desatualizados

7430d99

robertatakenaka requested a review from patymori July 20, 2026 19:50

patymori requested changes Jul 20, 2026

View reviewed changes

Adiciona ReadOnlyPrettyJSONWidget

5a396be

robertatakenaka requested a review from patymori July 21, 2026 11:18

patymori requested changes Jul 21, 2026

View reviewed changes

robertatakenaka added 2 commits July 21, 2026 11:33

robertatakenaka requested a review from patymori July 21, 2026 14:40

patymori requested changes Jul 21, 2026

View reviewed changes

robertatakenaka mentioned this pull request Jul 22, 2026

Reorganiza os testes do app location #1450

Merged

7 tasks

robertatakenaka requested a review from patymori July 22, 2026 15:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Traz para o core as atualizações já implementadas no upload para o app `pid_provider`#1449

Traz para o core as atualizações já implementadas no upload para o app `pid_provider`#1449
robertatakenaka wants to merge 11 commits into
scieloorg:mainfrom
robertatakenaka:aplica_refatoracao_pid_provider_upload_pr_1026

robertatakenaka commented Jul 20, 2026 •

edited

Loading

Uh oh!

patymori commented Jul 20, 2026

Uh oh!

patymori Jul 20, 2026

Uh oh!

patymori left a comment

Uh oh!

patymori Jul 21, 2026

Uh oh!

robertatakenaka commented Jul 21, 2026

Uh oh!

patymori left a comment

Uh oh!

robertatakenaka commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

robertatakenaka commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

O que esse PR faz?

Onde a revisão poderia começar?

Como este poderia ser testado manualmente?

Algum cenário de contexto que queira dar?

Screenshots

Quais são os tickets relevantes?

Referências

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

Ajustes no texto do PR

Uh oh!

patymori commented Jul 20, 2026

Uh oh!

patymori Jul 20, 2026

Choose a reason for hiding this comment

Uh oh!

patymori left a comment

Choose a reason for hiding this comment

Uh oh!

patymori Jul 21, 2026

Choose a reason for hiding this comment

Uh oh!

robertatakenaka commented Jul 21, 2026

Uh oh!

patymori left a comment

Choose a reason for hiding this comment

Uh oh!

robertatakenaka commented Jul 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

robertatakenaka commented Jul 20, 2026 •

edited

Loading