Olá, @B_D89,
Sim, a verificação das diferentes versões da publicação pode ser o próximo passo, principalmente comparando o current_publication_id com o issueId associado a cada publication_id . Entretanto, antes de partir para o banco, eu verificaria um detalhe no cadastro da edição.
Você informou que a edição futura possui volume, ano e título , mas não mencionou se o campo Número também está preenchido.
Como está sendo utilizado o sufixo padrão do sistema para o DOI , no OJS 3.3 o padrão utilizado para artigos é:
%j.v%vi%i.%a
Nesse padrão, %v corresponde ao volume e %i ao número da edição . O código do plugin DOI da série 3.3 busca explicitamente issueVolume , issueNumber e year da edição para montar os dados necessários ao identificador.
Portanto, eu verificaria primeiro em Edições → Edições futuras → Dados da edição se o campo Número está efetivamente preenchido.
Há um detalhe importante: no código do OJS 3.3, quando é usado o padrão padrão de DOI e falta algum dos elementos necessários, a interface utiliza a mensagem missingIssue . Por isso, a mensagem:
Você não pode gerar um DOI até que esta publicação tenha sido atribuída a um fascículo.
não significa necessariamente que o issueId esteja ausente. Ela também pode aparecer quando o padrão do DOI não consegue ser completado com os metadados da edição.
Há inclusive relato semelhante no fórum do PKP, em que a publicação estava atribuída à edição, mas o DOI não era gerado porque faltava um dos elementos utilizado pelo padrão. Fórum PKP
Se o campo Número estiver vazio , acredito que esse seja o primeiro ponto a corrigir ou avaliar. Caso o periódico trabalhe com publicação contínua e deliberadamente não utilize número, pode ser necessário avaliar um padrão personalizado de sufixo que não utilize %i .
Se o Número também estiver preenchido , então concordo com a sua hipótese: vale verificar todas as versões da publicação.
Nesse segundo cenário, eu compararia:
-
submissions.current_publication_id ;
- todos os
publication_id da submissão;
-
status de cada publicação;
-
issueId de cada versão em publication_settings .
O objetivo é confirmar se o issueId da edição 42 está associado à mesma publication_id indicada em current_publication_id .
Por exemplo, uma situação como esta seria bastante significativa:
current_publication_id = 541
publication_id 530 → issueId = 42
publication_id 541 → issueId = NULL
Nesse caso, a edição estaria associada a uma versão da publicação, enquanto a guia Publicação/DOI estaria trabalhando com outra versão corrente sem issueId .
Essa hipótese é plausível na série 3.3 porque o issueId era armazenado em publication_settings . O PKP inclusive registrou o bug #6584, no qual a remoção de uma publicação de uma edição podia deixar o issueId antigo persistido nessa tabela. Posteriormente, o próprio PKP decidiu normalizar essa relação, movendo o vínculo da edição para a tabela publications na linha 3.5. GitHub
Então eu seguiria nesta ordem:
1. confirmar se o campo Número da edição 42 está preenchido;
2. se estiver, comparar current_publication_id , publication_id e issueId das diferentes versões;
3. somente depois avaliar eventual correção de dados.
Eu evitaria qualquer alteração direta no banco antes dessa confirmação.
Quanto ao {$issueName} aparecer literalmente, parece ser um problema adicional de localização/interpolação/tradução da interface. Como o link aponta corretamente para a edição, eu não o consideraria, isoladamente, como evidência de que a associação com a edição está ausente.
Abraços!