In managing a journal there is a complete team which consists of a team of journal managers, editors, reviewers, copy editing, and others. However, as we know that the core team that is more dominant in the development of a journal is the Journal manager and Editor team.
Because these two user roles have almost no difference in role access in OJS 3, especially in the all latest version 3.3, journal managers and editors can configure and develop content in a journal, but please note that there are similarities in role access for these two users. can lead to deficiencies or advantages in journal management, see more detail in the explanation below.
With the similarities in the two access roles, an Editor can immediately assist in updating and editing content in the journal, so there is no need for the approval of a journal manager/admin again in every change process that will be made.
Not only have several advantages, many of the journal managers also do not agree regarding the similarity of access to these two users, because if we look at the OJS 2 system, these two users really apply a special job desk to these two users, for example the journal manager user is only responsible for content management, display, plugin installation as well as user management in the journal, while the user journal Editor only focuses on process management and workflow submission so that user editors do not have access and responsibility for any journal information content.
This is also a concern because many of the journal editors are not genuine people from within the relevant agencies or the old managers have been replaced with new editors, and even many user journal editors registered in the journal come from various countries. So it is likely that some curious users will see and access user settings in a journal. And one of the bad effects is as in the discussion of the current article where there is a configuration in the journal that has been removed and causes the galley button (pdf) on the article page to disappear.
As explained in the above, this is one of the causes of another user manager/editor who has accessed the workflow menu in ojs, and deleted one of the article components on the menu. (see sample image).
The assumption we have found regarding this problem is that one of the journal managers wants to make component articles so that they are uniform to be used the same in all articles that will be published so that some previously available article components that are considered unused will be deleted, even though he does not know that the other component articles have been used in the old article issue. So that the impact of this deletion is not immediately realized by the manager, considering the impact of the loss of the pdf galley on the article page only has an impact on old issues.
You can also see other similar issues here
How to fix this issue ?
In the initial checking process, what we did before finding the cause of this problem was to take the following actions:
- We analyzed and compared the use of categories and sections used in each problematic and non-problematic article
- We analyzed the issue metadata settings used in both problematic and non-problematic articles
- We ensure the configuration of open access to the journal and the availability of pdf galleys on every old and new article
- We also check the type of each article component used in old articles and new articles
After doing the checking steps above, we finally found that all the old articles used components that were different from the new releases, in which the old articles components were no longer available in the OJS workflow.
So to find out the configuration of the old components, we checked the tables in the OJS database. To be able to find the article compens table in the database, you can see it in the “Genre” table.
Like the picture above, we found that every component created in the previous journal has been deleted, then the record for the deleted article component will change to “0” (see the enable column).
So if you find the same problem which has many inactive components, then please activate each component one by one by changing the value “0” to “1” in the enable column. Then every time you activate the component, please refresh and check on the issue page of the problematic article.
If you have found the right article components, then the article page results will display results like the following:
After getting all the articles that have displayed the pdf, then the process of activating the article component has been successful.
This is not entirely the fault of a Journal manager/editor, considering that every journal manager/editor has different journal development goals and missions. However, this can be anticipated more strictly in assigning the duties of an editor or journal manager. Especially if we know that in the OJS 3 version, the JM and Editor user roles have the same access rights. So that an admin/JM can be more selective in giving editor access to new/other users.
Not only that, there will be several other obstacles that may be encountered in the submission process for each journal, so as to anticipate more by configuring backups automatically.
If you want get notification about the security issues, new features of the OJS version, and other must-know issues about the publishing platform.
Subscribe now to get the latest news! Join with Telegram channel: