Migração OJS 2 - OJS 3 - Congelamento da base para trabalho

Prezados, estamos tentando realizar a migração da versão 2.4.8.0 para a 3 e a equipe de TI perguntou se é possível “congerlar a base de dados” o que permitiria assim só a consulta dos artigos, sem submissão, avaliação, onde poderiam trabalhar a mesma base na versão nova e deixar a velho no ar até o momento da troca.

Não sabemos se isso é possível. Se sim, gostaríamos de uma orientação.

Agradecemos!

1 curtida

Prezado @andreluizdetoledo, as configurações de recebimento de artigo podem ser feitas pelo Gerente da Revista, na interface administrativa do sistema. Seria interessante criar uma notícia no OJS informando sobre a atualização da base e que por esse motivo novas submissões não estão sendo aceitas.

Para bloquear o recebimento de submissões basta restringir todas as seções para editores. Neste post tem a explicação detalhada.

Sobre as avaliações, pode ser que tenham artigos que estão passando por todas as fases do fluxo editorial (avaliação, editoração, diagramação e etc.), é ainda mais importante avisar toda a equipe que após a realização do backup da base (vocês devem definir internamente quando isso acontecerá) não deverão mais ser incluídas informações.

É importante lembrar que o processo de atualização deve ser bastante criterioso e nunca deve ser feito diretamente no ambiente de produção. Em outras palavras, vocês devem manter a base atual como ambiente de produção, mas “congelado” (seguindo os procedimentos que descrevi acima) e em outro ambiente, que é chamado de homologação, é feita a atualização escalonada. Subindo de versão em versão para evitar problemas. No Guia do usuário do OJS 3 tem um capítulo específico para atualizações. Aqui no fórum vocês encontrarão muitas informações e dicas sobre o processo de atualização.

Com a atualização feita, a equipe editorial deve validar as funcionalidades e garantir que nenhum dado for perdido. Depois do ok da equipe, aí sim essa base de homologação pode se tornar de produção. E a anterior, pode virar um novo ambiente de testes do OJS. Sempre que forem feitas correções, atualizações, necessidades de backup, sigam essa rotina: uma base de homologação e a outra base de produção.

1 curtida

Prezado @bernardo, bom dia!

Suas orientações ajudaram muito.

Temos outro desafio agora: na migração, os documentos suplementares estão visíveis e mesmo customizando os itens de “Componentes do Artigo” em Fluxo de Trabalho, o problema ainda permanece.

Descobrimos que o parâmetro Exibir documentos suplementares nas configurações do versão OJS 2.4.8.0 estavam habilitados, e não sabemos se isso interferiu no resultado da importação para a versão 3.3.0.8. Fomos orientados para tentar configurar na versão estável 3.2.1.4.

Interagimos com alguns posts relacionados e por enquanto, estamos sem poder colocar no ar a nova versão, até conseguirmos solucionar esse problema.

1 curtida

Oi, @andreluizdetoledo, me tira uma dúvida: esses documentos suplementares estão visíveis nos artigos?
Acho que aqui cabe uma explicação sobre configurações do sistema. O que acontece, quando você faz alguma configuração no OJS, aquilo passa a valer a partir do momento da alteração e não tem efeito retroativo. Ou seja, se existem artigos que já foram publicados utilizando alguma regra do fluxo de trabalho, você tem que fazer a alteração em cada um desses artigos.
A área de Componentes do Artigo afeta no upload de arquivos, tanto por parte do usuário leitor, quanto por parte do usuário equipe editorial, mas só terá a customização efetiva em novos uploads a partir da nova regra.

Não ficou muito claro para mim o que está acontecendo. Se você puder adicionar algumas imagens, acho que vai ser mais fácil de poder fazer o direcionamento.

Obrigado!