The problem is that the “Journal Editor” can enter the same options as the “Journal Manager” so both have the same “Permission Level”. In other words, both are “Journal Manager”. This did not happen in OJS 2.4.X, the editor could not enter to modify the “About …” for example.
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 editor with the content was artificial. Re-introducing that distinction would require code changes.
Regards,
Alec Smecher
Public Knowledge Project Team
Would it be possible to changes the codes? We have several editors that need access to the journal issues but do not wish to receive notifications everytime a new manuscript is submitted. With the journal editors having the same roles as the journal manager, they receive everything. Couldn’t the journal manager assign the journal editor after the manuscript has been submitted? This would prevent them from receiving unnecessary notifications, etc.
This is definitely something that we will need to look into before migrating to OJS 3. Many mid/large journals (and even lots of small ones) will have separate journal admin teams vs the editorial teams. Having only one permission level will mean that they will both see irrelevant options to their role. Many editors will also not know the intricacies of the management settings and thus journals are more open to errors being introduced by editors taking tasks upon themselves when theses are supposed to be controlled more centrally (e.g. as a publisher, we need to be involved in policy decisions). Even if some editors do need to have the journal manager permissions, it is still likely that this would be on an individual basis and not applied to everyone at the editorial level.
If nothing else I want Editors to focus on editing and not have the distraction of journal management, and I want journal managers to not have their interface diluted by editorial handling data, unless the settings/data are relevant. The OJS 2 division dealt with this very well, as it allowed each permission to be assigned on a user-level, providing the flexibility needed for different journal needs. The all or nothing option in OJS 3 will mean either a lot more training or trust that editors won’t click buttons that we don’t want them to.
I completely agree with TimW. We deal with lots of editors who do not have the skills to make the changes at the journal and website settings level or they might introduce changes which are not compliant with the overall objectives of the sites. I therefore support the separation of the Journal Manager and Editor permissions so that they can be allocated as required.
We host OJS for our journal editors on our site and provide them with support and infrastructure for their publications. The dissolution of the distinction between journal managers and journal editors is a major issue for us, too, though for an additional reason.
We fall under the jurisdiction of the European Union and we are currently in the dire situation that we cannot provide our journal editors with the access capabilities and permission levels that they need and should have, because it would violate the General Data Protection Regulation of the European Union (GDPR). The Configuration Recommendations for GDPR Compliance (Configuration Recommendations for GDPR Compliance) do not provide us with a solution. In particular, the user account management is a problem.
It provides users who hold the permission level of journal manager not only to access the account information of every user who has a lower permission level than them, but it allows them to change it without their consent or any kind of notification, and most problematic, it even grants them the power to log into their accounts and use them as if they were the specific user himself/herself (see screenshot).
We understand that this kind of function is pretty helpful to operate the site. For example, as our journal’s host, we are obliged by the GDPR to provide users with the service to delete their accounts. With the current user account management it is very easy for us to do this. However, this kind of access should be limited to a small number of people, at best to only those who manage the site. It should not be granted to everyone who holds an editorial position.
Our editors should be able to use the whole submission, review and production workflow as well as the issue and publication management but they should not be able to enter the settings of the whole site. The dissolution of the distinction between journal manager and journal editor does not only enable unnecessary sources for blunders and mishaps, but also poses a serious liability issue and might potentially open the floodgates to (severe) violations of the GDPR.
After extensive consultation by our legal advisor we had to “downgrade” all of our editors to the permission level of section editor. We developed a workaround that allows them to use the whole submissions process, however, they are not able to use the issue menu. Rather, issue management has to be done by us for them. This can only be a temporary compromise to a problem which has an easy solution: adding a new permission level of journal editor who has access to the submission and issue menus but not to the settings. This would accommodate the users of OJS that need the specific distinction between site management and editorial work while the apparent majority of editors who hold both positions for their journals could simply keep using a role that holds the journal manager permission level. We imagine that we cannot really be the only ones who have met this legal problem.
I’m not personally very familiar with GDPR requirements, but we did a GDPR review with a number of partners who are working more closely with it and this issue didn’t come up. Hopefully we can get a few opinions from that group.
Downgrading your Editors to Section Editors is a pretty drastic step. Fortunately there’s a single logical check in the code that’s used for the kinds of user administration concerns that you’re raising (Log In As, editing user accounts, etc). (If you’re OK with code, it’s implemented in lib/pkp/classes/security/Validation.inc.php, in the canAdminister function.) That’s where the current policy is coded – essentially you can perform these tasks on a user account, if you’re a user with a managerial role (Journal Manager and Journal Editor are both examples) you hold managerial access over all journals that the administered user is enrolled in. It might be possible to further specify the restriction as only available to some managerial roles, i.e. Journal Manager and not Journal Editor, with an additional checkbox or similar.
Alternately, depending on how you’re running your journal, it might be enough to deprive all managerial users of the Log In As feature (and related functions), and leave it to only Site Administrator users. If that’s sufficient, a one-line modification to the code would achieve it.
Regards,
Alec Smecher
Public Knowledge Project Team
thanks for the quick reply. Your solution sounds good and uncomplicated. This will help us maintain a bit of the distinction between journal managers and journal editors. I will pass it on to our administrator.
hi @asmecher,
Just wondering if this issue is likely to be revisited in future releases?
I strongly agree with @sioux, @TimW, @dgardner, @azein that it is useful to distinguish a “journal manager” from “journal editor” as was previously the case.
We have recently migrated one journal which relied heavily on this distinction. The “journal manager” will now have to make a call about downgrading some editors to “section editors” (dramatically reducing their involvement) or deciding to accept that all “journal editors” are now “journal managers” with all the training, trust and GDPR issues that go along with that.
I couldn’t agree more with the arguments put by azein and others. Journal editors come and go, and often need help and guidance. We run several OJS installations on behalf of our editors, and much preferred the old system where editors were not automatically given full journal manager permissions.
This seems a bit of blind spot. It would be really nice if it could be addressed some time soon.
As we just upgrade our client’s OJS with 40+ journals, we received the same inquiry from many of the journal manager users for this issue. Since we cannot find any resources for fixing this problem, we decide to research and develop the code from our internal team.
We have shared some of the essential code if you need to implement the same solution for restricting “Journal Editor” authority, you can check our article here :
Any update on this issue?
Is it going to be addressed in future releases?
This is serious drawback for our journals as well. Journal editors should not have access to so many journal settings, which could be easily controlled by the journal manager in OJS 2 and kept unified among all journals of the same OJS instance. Currently, managing of the journals are much harder.
