Criar endpoint para criar Article a partir de PidProviderXML

[robertatakenaka]

Descrição da nova funcionalidade

Eu, como sistema de publicação (scms-upload), gostaria que o Core disponibilizasse um endpoint para registrar que um artigo identificado por pid_v3 e sps_pkg_name foi publicado ou atualizado no site público, então o Core possa recuperar os metadados do artigo no PidProviderXML, criar ou atualizar o registro de Article e, por consequência, disponibilizá-lo no OAI-PMH, que só expõe artigos com status público.

---

Critérios de aceitação

Para que esta tarefa seja considerada concluída, os seguintes pontos devem ser contemplados:

• O endpoint deve aceitar requisições POST com o corpo contendo ao menos pid_v3 e sps_pkg_name como parâmetros de identificação do artigo;
• Ao receber a requisição, o Core deve consultar o PidProviderXML usando pid_v3 e/ou sps_pkg_name para recuperar os metadados do artigo (título, autores, resumos, palavras-chave, DOI, ISSN, fascículo, datas etc.);
• Com os dados recuperados, o Core deve criar o registro de Article caso ele ainda não exista, ou atualizá-lo caso já exista (operação upsert);
• O Article criado ou atualizado deve ter seu status definido como público, tornando-o elegível para exposição via OAI-PMH;
• O endpoint deve retornar resposta adequada: 201 Created para criação, 200 OK para atualização, com o identificador interno do Article no corpo da resposta;
• O endpoint deve retornar 400 Bad Request se pid_v3 ou sps_pkg_name não forem fornecidos ou forem inválidos;
• O endpoint deve retornar 404 Not Found se o PidProviderXML não localizar nenhum registro correspondente;
• O endpoint deve ser protegido por autenticação via token, sendo acessível apenas por sistemas autorizados (ex: scms-upload), não por usuários finais;
• O mecanismo de obtenção de token deve seguir o padrão já adotado no projeto — endpoint dedicado que recebe credenciais (username/password) e retorna um token de acesso a ser enviado no header Authorization: Token <token> nas chamadas subsequentes;
• Deve haver registro de log da operação (criação vs. atualização, pid_v3, sps_pkg_name, timestamp);
• O OAI-PMH deve, sem alterações adicionais, passar a listar o artigo após a execução bem-sucedida do endpoint, uma vez que o filtro de elegibilidade já é baseado no status público do Article;
• Deve ser criada ou atualizada a documentação no wiki do projeto cobrindo:
  • Descrição do endpoint (rota, método HTTP, parâmetros, exemplos de request/response);
  • Fluxo de obtenção de token (endpoint, payload, formato do header de autenticação);
  • Comportamento esperado em cada cenário (criação, atualização, erros);
  • Pré-requisitos para que o artigo passe a ser exposto pelo OAI-PMH após o registro.

---

Anexos

N/A

---

Referências

• Modelo PidProviderXML — app pid_provider do Core
• Modelo Article — app article do Core
• Protocolo OAI-PMH implementado no Core e seu filtro de artigos públicos

[samuelveigarangel]

@robertatakenaka Pelo que entendi dessa lógica, os artigos passarão a ser processados apenas quando receberem o POST nesse endpoint do scms-upload?

Atualmente existe uma task que percorre o PidProviderXML, executa o processamento e cria os artigos. A ideia é manter ambos os fluxos funcionando em paralelo, mesmo realizando a mesma operação, ou essa task passará a ficar obsoleta com a nova implementação?

Na task responsável pelo processamento dos artigos, existe uma chamada para o método Article.check_availability()

core/article/models.py

Line 767 in 8e7b1fa

def check_availability(self, user, force_update=False):

, que ao final executa mark_as_available()

core/article/models.py

Line 809 in 8e7b1fa

def mark_as_available(self):

, e coloca status como publico.

Com a introdução deste endpoint, o comportamento esperado é remover a chamada para check_availability() do fluxo de processamento e deixar que o próprio endpoint seja responsável por publicar o artigo? Ou o artigo deve continuar sendo marcado como público durante o processamento?

[robertatakenaka]

@samuelveigarangel

Pelo que entendi dessa lógica, os artigos passarão a ser processados apenas quando receberem o POST nesse endpoint do scms-upload?

Não. O correto a afirmar é: os artigos passarão a PODERÃO ser processados apenas TAMBÉM E PREFERENCIALMENTE quando receberem o POST nesse endpoint do scms-upload

Atualmente existe uma task que percorre o PidProviderXML, executa o processamento e cria os artigos. A ideia é manter ambos os fluxos funcionando em paralelo, mesmo realizando a mesma operação, ou essa task passará a ficar obsoleta com a nova implementação?

Esta tarefa é assíncrona. O objetivo deste issue é ter mais uma alternativa síncrona para a criação/atualização de Article. Além disso, é bom sempre ter mais de uma forma de realizar operação. A tarefa que mencionou é para eventualmente poder processar em lote. Então, não deve ser removida.

Com a introdução deste endpoint, o comportamento esperado é remover a chamada para check_availability() do fluxo de processamento e deixar que o próprio endpoint seja responsável por publicar o artigo? Ou o artigo deve continuar sendo marcado como público durante o processamento?

Não remover check_availability(). Se há código feito, só reuse.