Description #
One of our clients complained that “Journal Editor” can have the same authority access as “Journal Manager”. This problem happened on OJS version 3. X In the previous version (OJS 2), this problem didn’t happen. The Journal Editor should have a restriction with different authority from the Journal Manager.
This complaint come out to our customer after we have upgraded their OJS that have 30+ journals. As they have accustomed to the role of Journal Editor in the previous OJS 2 version. We gain so much knowledge for this upgrade case and one of theme if the is this case. We heard their claim regarding this and try to find a solution somewhere by googling this problem. The problem apparently already an unsolved topic in the PKP forum that was complained about by many of the OJS users.
As explained by PKP staff on the forum.
“This was an intentional change with the redesign of OJS 3. X – for the vast majority of users, we heard that the distinction between the user who works with the journal setup and the user who works as an editor with the content was artificial. Re-introducing that distinction would require code changes”
After we discuss this with our client, we also heard many inquiries regarding the restriction of the user that has a role as Journal Editor to disallow any activity that is considered can only be done by Journal Manager. This is considered because, in many mid/large journal management, the Journal Editor is a guest user from outside the organization that founded the journal.
Many of these complaints come from the ideas on how OJS 2 manages the user role. In that platform, Journal Editor can only do some activity on submission files, make announcements, and do operations on an issue and in the manner that the Journal Editor cannot make any operation to modify how the journal is presented to the visitors and some configuration on the journal such as the checklist to the reviewer process and the list of the submission process by authors.
As our commitment to helping many of our clients to achieve their vision to be better publisher partners, we understand their request. Our research team discuss solving the problem and we come out with a solution to fix this problem by creating a plugin provided to our clients that need this solution. One of our examples is to make the OJS run 300% faster by deploying our plugin.
In this post, we want to share our approach to fixing the issue by sharing some logical steps. We hope this approach can help any internal developer that wants to implement the idea too.
Requirement : #
- Journal Editor only can access some menus including :
- Submission
- Issues
- Announcement
- Statistic and its child menu
- Restrict path location for the Journal Editor User when accessing the unlisted menu by manually typing the URL located in the browser address bar.
- Make the approach flexible by developing a plugin that allows another journal to disable the feature
Journal Editor Restriction Flow Diagram: #
Solving Problem #
In this post, we explain our approach to fixing this issue. Since we never get the solution from the forum, our team create an in-house plugin based on our client’s OJS version (3.3.10). Here we explain the core code that we have done on the plugin.
Registering a Hook #
Fortunately, OJS built with the implementation of the Hooks system. So we can fix many of the problems by utilizing this hook system and solve them with the flexibility of building a plugin. Reference about hook can be found here. Finding the right hook is the first step. After browsing the correct hook we add this code to our plugin :
Checking current user role #
After we add the hook, later we add the custom function that will validate the use role/check if the user is the Journal Editor
This function isCurrentUserAreJournalEditorAndNotJournalManager() later is a very important function that will detect and validate the user as it will be used in the Hooks function: loadHandler and setupBackendPage.
Removing Menu in setupBackendPage function #
The setupBackendPage function will be used for removing some of the menus that should not be appeared for the Journal Editor.
Here is the necessary code :
Restrict Journal Editor from accessing the disallowed page #
Removing the menu on the backend template does not directly disable Journal Editor to access some pages. Since setupBackendPage function removes the visibility of the menu. Some skilled Journal Editor may be accessing the menu by manually typing the location of the menu in the browser address bar.
To prevent this to happen, we modify the default loadHandler function with this code:
Result #
The menu when the plugin is activated.
Conclusion #
By sharing the core code that makes issues like this workable, we hope your internal developers can develop the same fixes our team has done. One might consider why we don’t provide this as a free plugin. After we learned that sharing many of our solutions as free plugins, we became overwhelmed when we received a lot of complaints from users that used the free plugins, since we are a small company with limited staff this is something that makes a burden for us. Many problems are caused by the OJS version being different from the version supported by the plugin and many of the users want our solution to be compatible with many of the OJS versions. So we decide to focus on sharing the solution rather than the free plugin for now.
Things to consider :
Although we have succeeded to implement the solution based on our in-house plugin, we find that the solution actually is not perfect and this is caused by the “hardcoded” permission level provided by the OJS that has the same level as Journal manager and Journal Editor you can see here :
We try to find a solution to make the plugin more flexible, unfortunately, the permission level cannot be overridden by the plugin as it is hardcoded in OJS. The problem with this is that when the Role Name is renamed from Journal Editor to another name by the Journal Manager, this plugin won’t work as expected.
That’s it, I hope this post will be useful for you in solving the same problem that we have faced when we handled large OJS upgrades.
Thank you for reading our post.
