Describe the issue or problem
Users who have the Journal editor role and are assigned as participants on articles do not automatically have “Allow this person to make changes to the publication, such as the title, abstract, metadata and other publication details…” checked under Edit Assignment.
This seems to be a recent problem and it is causing a lot of headaches. Is there some way to have the box checked by default for Journal editors?
Steps I took leading up to the issue
A journal editor is assigned as a participant on an article.
They try to schedule the article for publication, change metadata, etc. but get the message “You are not allowed to edit this publication”.
They can go in to edit the assignment and give themselves Permissions to make changes, but it would be much easier if they had those permissions by default. Is there some way to make this standard?
This is still an issue for us, with several editors contacting us weekly when they are unable to carry out some basic function with a submission. Anyone else having this problem and/or have an idea how to fix it?
Hmm, this isn’t entirely making sense to me. But can you try making a change to see if it helps?
Edit lib/pkp/controllers/grid/users/stageParticipant/form/AddParticipantForm.inc.php and find the lines (around line 86):
/**
* Determine whether the specified user group is potentially restricted from editing metadata.
*
* Subeditors can not change their own permissions.
*
* @return boolean
*/
protected function _isChangePermitMetadataAllowed(UserGroup $userGroup, int $userId) {
$currentUser = Application::get()->getRequest()->getUser();
if ($currentUser->getId() === $userId && $userGroup->getRoleId() === ROLE_ID_SUB_EDITOR) {
return false;
}
return $userGroup->getRoleId() !== ROLE_ID_MANAGER;
}
You’ll see a strict comparison (=== and !==) in three separate places. Try changing those to a normal comparison (== and !=) instead.
If I guessed right, what you should expect to see is that all editor/journal managers should implicitly be able to edit metadata, and the checkbox to allow/prevent that shouldn’t even appear on the form.
Regards,
Alec Smecher
Public Knowledge Project Team
We changed the lines as you suggested, and it seems to have worked! Many thanks for the fix, Alec! As you suspected, now the checkbox for permissions doesn’t even show up. This saves us a ton of trouble.
Will this fix be included in the next version of 3.3 that is released, or do we need to make a note to make the change again when we do a minor upgrade to the next 3.3 version that comes out?
This appears to be related to a mysterious change in PHP that I haven’t been able to fully pin down or replicate locally; see also this thread/post. But yes, I’ll get the change included in the next release of OJS, which should be out in perhaps a month.
Regards,
Alec Smecher
Public Knowledge Project Team
I’m still struggling to find out what exactly it is about your environments that’s causing them to behave in this way. If possible, could you send me a private message with your phpinfo() output? That’ll help determine how common this is and how best to treat it.
Thanks,
Alec Smecher
Public Knowledge Project Team
