OJS version: 3.1.1.2
A user has requested the possiblity of deleting submissions.
The user in question is an editor, and she can’t delete submissions because the Delete button will not show up in the interface. The other editors are able to delete submissions though.
The editor in question has the following roles in the OJS3 journal:
Journal manager
Journal editor
Section editor
Author
Reviewer
In addition this user is assigned as Editor in all Sections in Settings > Journal > Sections
I tried to create a new account for her, then merge the old account into the new account and assign the same roles. Then the Delete button would indeed show up in the interface of the new account.
However ‘My Queue’ for the new account would be empty, as the merge users function did not update the stage_assignments table with the new user_id. I did a manual database update, changing all occurences of the old account’s user_id to the new account’s user_id in stage_assignments.
Doing this, all submissions reappeared in the user’s ‘My Queue’, however, then the Delete-button for deleting submissions again does not show up in the interface, and we’re back where we started.
For now I have adviced her to log in as another editor or journal manager if she needs to delete a submission, and I have also adviced to really think if they need to delete declined submissions, considering preserving the history.
What could the reason be that this editor does not get the delete-button in the interface?
Me and my colleague finally found the solution to this issue. Even if the user in question has the roles of Journal manager and Journal editor (who has the same permission level as a Journal Manager, including permission to delete submissions), in this case the user was assigned to the articles as Section editor from Submission > Participants > Assign.
Section editor does not have permissions to delete submissions, and this restriction will overrule the role of journal manager/journal editor for the submission in question.
The solution is therefore to assign the user as a journal manager instead of (or in addition to) a section editor in Submission > Participants > Assign if the user wishes to be able to delete a submission.
I think that makes sense although it is not too transparent. Or do you think that the journal manager permission level should always override the fact that the user is assigned as a section editor.
Personally the current behaviour was very counter intuitive for us and we had to do a lot of experimentation before we finally understood. I think that the journal manager permission level should always override the fact that the user is assigned as a Section editor.
Also, If there is only a single section editor assigned for a section in the journal, this user is automatically assigned as Section editor for the submission. If this user is usually has journal manager rights, confusion will arise. In our case, a phd student has the technical responsibility in a journal, and she holds the roles of journal manager, journal editor and section editor. She is also the one assigned as section editor for every section in Settings > Journal > Sections, so she automatically gets assigned as Section editor for new submissions.
Often, authors re-submit submissions instead of updating them, hence the need to delete submissions on a regular basis.
If the current permission behaviour is not changed, the user should be informed how to work around the issue.
For instance instead of the delete-button, OJS could detect that the user is assigned as section editor and also normally has journal manager permissions,
Instead of the delete-button, the user could be presented with a link to a popup with text explaining that since the user is assigned as a Section editor, it can’t delete the submission, however if the user chooses so, it can assign itself as a journal editor or journal manager (with a button on this popup page), to gain these rights.
Then the user could finally delete the submission.
Sorry for the confusion and thanks for the explanation. We made a decision a couple versions back that when a user is assigned to a submission in any capacity, we will grant them permissions according to their assigned role.
This accounts for all kinds of tricky situations where a journal manager/editor may also act as author or reviewer. It does introduce some confusion, but we felt it was important to minimize the exposure of blind reviews, even if a manager acting as author/reviewer is a discouraged practice. It also provides a clearer record in the activity log. If a user assigned in one role wants to perform an action in another role, they need to assign themselves in that role, and that assignment is then tracked.
In your case, I would advise against deleting submissions. If an author makes a new submission when they should submit revisions, you should either request they use the appropriate revision submission area or manually move the revisions over to the original submission. By deleting the original submission, you will lose all activity logs, which can be important when allegations of misconduct arise and an audit is requested of the full review process.
In addition, I’ll mention that we’re planning over the next year or two to provide more features for monitoring editorial stats, such as time to review, number of review rounds, ratio of submissions that make it through review, etc. If you are regularly deleting submissions, rather than archiving them, you will skew the data.
Late thanks for your reply.
I will ask the journal managers to archive duplicate sumissions instead of deleting them.
Best,
Eirik Hanssen
OsloMet University Library
I am attempting to clean up our Active submissions list by deleting “Incomplete” submissions. However, I am having trouble locating the option to remove them. I am only assigned as a Journal Manager.
Do these submissions have to go through all steps of the submission process to have the option to be deleted? I’m getting mixed answers from various forums and just wanted to reach out to see if there is a more straightforward way to accomplish this. I look forward to your advice.