Have option to restrict Editor access to Settings

[amandastevens]

Update
This is how the solution is implemented:
Now there is the possibility to allow or disallow access to "Settings" for roles with the "Journal Manager" permission level (per default these are Journal Manager, Journal Editor and Production Editor) -- there is a new setting option "Permit changes to Settings" in the roles edit form, that is only enabled for roles with the "Journal Manager" permission level.
Per default all default roles with the "Journal Manager" permission level, i.e. "Journal Manager", "Journal Editor" and "Production Editor" are allowed to access "Settings".
The journals that would for example like "Journal Editor" role not to have access to "Settings" would need to deselect that new setting option. In that case the users with the "Journal Editor" role will have access to all other left menu items except "Settings". They would have access to for example Submissions, Issues, Announcements, DOIs, Statistics, Tools, Institutions, Payments. Differently to the original requirements mentioned below, such users will also not have the access to Users settings.

---

Describe the problem you would like to solve
In OJS 3.x the Journal Manager and Editor roles have access to the same parts of the dashboard. This works for some journals but not others where the responsibilities of each role are distinct. Some Journal Managers do not want their Editors to have access to the Settings menus in case they change something they shouldn't. It can also make the interface unnecessarily busy for Editors who do not do any work in Settings.

Describe the solution you'd like
Having some option to limit Editors' access to Submissions, Users & Roles (or at least Users), and Statistics would be ideal. There are a few different ways this could be done, including adding new sets of permissions for roles or making the Editor and Journal Manager roles distinct.

Who is asking for this feature?
This was requested by a Publishing Services client and has been requested multiple times on the PKP Forum.
https://forum.pkp.sfu.ca/t/journal-manager-and-journal-editor/46064
https://forum.pkp.sfu.ca/t/excluding-journal-editors-from-settings/46885

PRs:

• pkp/pkp-lib#5504 Control access to settings by user group #10380
• pkp/pkp-lib#5504 Control access to settings by user group ojs#4431
• pkp/pkp-lib#5504 Control access to settings by user group ops#774
• pkp/pkp-lib#5504 Control access to settings by user group omp#1700

[NateWr]

Maybe I'm not interpreting this correctly, but I think we already support such a setup. Underneath the user-facing list of roles (Journal Manager, Journal Editor, Section Editor, etc) we have a simplified permissions system that works like this:

Role	Permission
Journal Manager	ROLE_ID_MANAGER
Journal Editor	ROLE_ID_MANAGER
Section Editor	ROLE_ID_SUBEDITOR

It should be possible to create an alternate setup that would restrict the editor's access.

Role	Permission
Journal Manager	ROLE_ID_MANAGER
Journal Editor	ROLE_ID_SUBEDITOR
Section Editor	ROLE_ID_SUBEDITOR

Would this cover the scenarios that you describe?

[amandastevens]

If the Journal Editor is given the role_id of subeditor would they still have access to all submissions or only submissions they have been assigned to?

[NateWr]

Ah, I see. No in that case they'd only have access to assigned submissions. This case is something like an assigning editor that has global access to submissions but not to journal configuration.

[amandastevens]

Yes, exactly! And ideally user accounts as well.

[asmecher]

Just a bit of history: Dissolving the distinction between Editor (who works with content) and Manager (who works with settings) that we used to maintain in OJS 2.x was a conscious choice for 3.x -- a lot of people were spending a lot of time clicking between roles when the distinction wasn't relevant to their journals. However, I didn't predict the pushback from the small group of users who do depend on the distinction.

[pmangahis]

We have another hosted client with a number of journals that would be interested in this.

Ideally, the Journal Editor should not have full Journal Manager privileges. The only dashboard items they would have access to is submissions, issues, statistics (similar to OJS 2).

As well as the option to grant access to the user accounts (user tab only) to certain roles (an assistant level) to be able to modify user info but not create new roles types, and site access setting.

[shantanu198713]

Hi @asmecher
I think journal manager and journal editor should be separate. Sometimes the journal editor changes some settings of the journal which he does not want to do and later a problem arises.
So please differentiate between the JM and JE.

[asmecher]

PRs:

• pkp/pkp-lib#5504 Control access to settings by user group #10380
• pkp/pkp-lib#5504 Control access to settings by user group ojs#4431
• pkp/pkp-lib#5504 Control access to settings by user group ops#774
• pkp/pkp-lib#5504 Control access to settings by user group omp#1700

To be resolved:

• Actually prevent access to settings -- this will only hide the menus at the moment.
• Decide how/when to protect users from footgunning themselves by unchecking the setting in their own user group

[asmecher]

Thanks, @bozana! I fixed the things you identified; about this comment:

• OJS SubscriptionsGridHandler: This is a production operation, and outside the settings area, so I think it's fine.
• LanguageGridHandler: This is covered by lib/pkp/controllers/grid/settings/languages/ManageLanguageGridHandler.php
• SubmissionLanguageGridHandler: Added CanAccessSettingsPolicy

What about other API Controllers, e.g. institution, highlights, emailTemplates, invitations?

I added the check to PKPEmailTemplateController.php, but not highlights, institution, or invitations, which are used for production concerns outside of settings.

If that covers everything for you, let me know, and I'll set up a testing install for a run through with Magnus and Beau. Much appreciated!

[bozana]

Hi @asmecher, all good, you can proceed... Thanks!

[mreiko]

Since this ticket has a bit of a history, wondering if @bozana, you can create an updated summary at the top so the testing requirements are clear for Beau?

[Tribunal33]

Oh that's a great idea @mreiko. I messaged @asmecher and ask for some specific details regarding the requirements to verify for this issue. Based on this criteria I can write up a manual test case to capture these requirements.

I wrote Alec "For example what specific parts of the site would the journal manager be able to still view compared to the journal editor? I believe the issue was with settings and statistics but is that all and did I understand it correctly?"

[bozana]

Hi @Tribunal33, @mreiko and @asmecher, I have just added an update at the top of the issue, how it is implemented now. Alec, please change as needed.
Beau, I will try to help and answer you question here:
You could test selecting and deselecting of the new setting "Permit changes to Settings" in the role edit form. The setting should be clickable/usable only for the roles with "Journal Manager" permission level. You could also try to create new roles.
You could deselect that option for a role, e.g. for the role "Journal Editor", then log in as a user with "Journal Editor" role and test if you would have access to "Settings" -- you should not be able to access anything from the "Settings" area in that case. You could eventually also try to access the URLs from the "Settings" area (having them from another installation) -- so that we are sure that such a "Journal Editor" not just cannot see the "Settings" area, but that the settings function from that area are not accessible by just entering their URLs. So the difference is only the access to the "Settings" area.
I think that was it 🤔 If something else crosses my mind I will write.
And if you would have any further questions, please don't hesitate to ask.
Thanks!

[mreiko]

@Tribunal33 I created a new status for this PKP Dev Coordination project called "Ready for Testing" and updated this ticket to that new status.

@asmecher I wonder if we can eventually make the dev-team repo public? The reason being, with a private repo, I believe that GitHub doesn't allow users to set notifications (i.e. it would be handy if Beau would be notified when a ticket flips into "Ready for QA") nor does it allow multiple assignees (less of a big deal). And I don't think comments and updates to tickets appear in the dashboard feed which I use to view all activity.