Ability to disable submissions in OJS3

[PeterfordUP]

Editors and Journal managers need to be able to stop new submissions being created for specific journal sections.

Often this is done when a journal stops accepting or publishing a particular kind of article, where the journal section will still need to exist with all settings in place (as it applies to published articles), but no new submissions should be allowed. Sometimes this is temporary, sometimes permanent.

There is also a use-case for new submissions to all sections to be disabled, when journals are closed-down but still hosting content, or live but not accepting new content due to temporary organisational factors, etc.

Currently, @ajnyga has mentioned that the only way to achieve part of this functionality is to edit section settings so that only editors can submit to the section. However, this does not stop submissions from all users, nor is it evident that no new submissions should be created, from this solution. Often there are large numbers of editors, and new editors over months/years, so relying on self-controlled user behaviour is a poor solution.

An ideal solution (solution A) would be:

• the 'sections' tab on the journal settings page features an on-off slider for each journal section, which disables new submissions to that section, located to the right of the 'Editors' column (see image1);
• the same 'sections' tab also features an on-off slider next to the 'order' and 'create section' options, which overrides all the sliders below and greys them out (see image1); and
• the journal section is greyed-out or removed from the drop-down list in the submission form when disabled (see image3);

An acceptable solution (solution B) would be:

• a checkbox in each journal section admin page, labelled 'Disable new submissions', which disables new submissions to that section (see image2); and
• the journal section is greyed-out or removed from the drop-down list in the submission form when disabled (see image3);

Notes:
Solution A is preferable because:

1. it co-locates the enabling/disabling of a section with other 'top-level' settings (e.g. edit, delete, order, create), on the 'sections' tab. We feel that the enabled/disabled status of a section is not hierarchically similar to a setting/property of that section, e.g. word counts, section policies, etc.
2. it allows for the enabled/disabled status of all sections to be seen on the same page, and edited there in real time, whereas solution B requires one-by-one editing, viewing the status of only one at a time, relying on the user remembering which have or have not been edited.

[ajnyga]

Related discussion here: https://forum.pkp.sfu.ca/t/how-do-i-disable-submission-option/40021
This has been on my todo list for a long time because it is needed for Journal.fi.
Likely to solve this during the next months.

[PeterfordUP]

Hi @ajnyga ,
Do you have any thoughts on the specifics of the functionality we've proposed, above?
We're happy to assign resource to this and or assist with a solution, or if there isn't a firm timeline in place, we can begin working on a solution from scratch.
Best,
Peter Ford (PM, Ubiquity Press)

[ajnyga]

I think that the ability to stop accepting submission to a specific section is already there. You can just select that only editors can submit to the section. Is there a reason why this might not be enough?

I guess what I have been thinking about is a journal level setting that will block all incoming submission. Enabling the setting would:

• hide the "New Submission" button from non-editorial users
• block access to submission form for non-editorial users
• hide the "Make a new submission or view your pending submissions." dialog from the public about/submissions page

So a master switch for stopping all incoming submission and for those journals that want to receive submissions for example by email (or in a scroll delivered by a runner). They can then just edit the author instructions incordingly.

[fradeve]

@NateWr @asmecher we are very keen in implementing this ASAP (i.e. in the next couple of weeks): do you have any recommendation on whether it is worth implementing this in pkp-lib rather than a plugin? If pkp-lib is your suggestion, we can finalise the PR very soon, so that this can be included in the upcoming summer release

[NateWr]

Hi everyone, sorry I missed this when it came in. Yes, I think this would be good to have as part of the core application. A few suggestions on how I'd like to see it:

1. Can we call it "archiving a section" and refer to it as an "archived" section? I think this reflects the use-case you describe and would better model how sections are handled throughout the application. This should go into the section table as is_archived.

2. I'd like to see the enabled/archived toggle in the section list as described in Solution A. However, instead of a toggle let's make it a checkbox to align with similar practices in other parts of the application. (It also gets around some tricky a11y concerns with toggles.) Let's also add it as an option in the section editing page. Allow editors to make the setting in whichever way they discover.

3. Let's skip the "disable all sections" toggle in the sections grid. If we want to disable submissions at the journal level, lets add a new context setting submissionsEnabled, and handle it at that level. This will make it easier to do some of the things that @ajnyga suggests, like hiding the new submission button, etc. I'd like to see this added in a new tab under Settings > Workflow > Submission > Allow Submissions. When submissionEnabled = false, let's add a <notification> to all settings pages and to the Submissions page in the editorial backend which indicates this. We should also update the frontend submissions page so that a link to start a submission is not there.

4. In the last screenshot, you suggest greyed out or strikethrough for archived sections when submitting. Instead, let's not show them at all in the list.

A few things to look out for during implementation:

• Submissions can be generated through the REST API now so it should also not be possible to submit via the REST API (the submissions form hasn't been converted over yet but it will get there).
• The validation check, which ensures the submission can be made in the journal+section should be in PKPPublicationService::validate().
• Archived sections should not appear as filters in the My Queue and Unassigned submissions list. They are only need in the All Active and Archived lists.
• It should not be possible to archive every section. At least one section should be not archived, unless the journal setting submissionsEnabled is false. This will prevent situations where the submission form is available but no sections can be submitted to.

Let me know if this sounds like it will work for your needs and if you'd like any guidance on moving forward. 👍

[PeterfordUP]

Hi @NateWr
Thanks so much for this - this works for our needs, and we'll work on implementing this as you suggest.
Big thanks for the list of things to look out for, too. That'll be a real help.
One question, please could you explain a bit further what you mean by

When submissionEnabled = false, let's add a to all settings pages and to the Submissions page in the editorial backend which indicates this.

We weren't sure what you were referring to, when you wrote about a . Was that a new pop-up notification, like the one that appears when enabling/disabling a plugin, or something more akin to a banner across the top of the page. The banner option makes more sense to us, since it needs to be on multiple pages, but I wanted to check in case there was something else on your mind.
Best,
Pete
(PM, Ubiquity Press)

[NateWr]

something more akin to a banner across the top of the page

Yep, I'm imagining a prominent banner that says "Submissions to this journal have been disabled. Visit the workflow settings to enable submissions."

[PeterfordUP]

Awesome - glad we're on the same page. Thanks!

[fradeve]

@NateWr in your comment on #5806 you suggested that it would make more sense to have the ability do disable submissions in the core code rather than a plugin (as we realised in #5806, we would need changes to pkp-lib in any case in order to have this feature in a plugin).

Would everyone (I am thinking of @NateWr and @asmecher in particular) be happy if we open a pull request in pkp-lib / OJS to make this feature (as defined above) happen?

Thanks again for your support! 👍

[NateWr]

Yep! If there are any disagreements we can't resolve about what should be in core then we can figure out what hooks are needed to separate that piece out into a plugin. But let's presume that disabling submissions and archiving sections will be core settings.

[fradeve]

Thanks @NateWr for the quick reply! We are happy with any solution you are comfortable with 😃

Since specs have been agreed above, we are happy to start the implementation and submit a PR to be reviewed by all contributors. We might also submit the PR when it will be half-done in order to get some earlier feedback from you guys, just in case you have any preference on how things should be implemented (and we can start this conversation sooner rather than later).

Thanks again, we will link the PR in this conversation once with open it 👍

[PeterfordUP]

Hi @NateWr ,
Can you tell us a bit more about why it's important to have the disabling of submissions to a journal section be called 'archiving' the section? You mentioned in your post above, that

Can we call it "archiving a section" and refer to it as an "archived" section? I think this reflects the use-case you describe and would better model how sections are handled throughout the application. This should go into the section table as is_archived.

We would like to still refer to it as 'disabling submissions' if at all possible, partly because we expect journal sections to be prepared in advance as part of the use case (but kept as disabled until release), and also for submissions to be temporarily disabled with every intention of taking submissions in the future, or at the very least with every intention of the content still being live and an ongoing part of the journal. None of these use cases fit with the implications that come with 'archiving' - that the journal section has 'ended' or has been put to rest. It's a bit too 'final' sounding, is what we fear.

We do however concede that the semantics here may not be terribly important in the grand scheme of things, but we hope that the best wording can be found. Perhaps there can be some compromise in that the front-end UI displays the text as 'disabling submissions' but the code refers to 'archiving'?

Would love to hear your thoughts on this. Hope you're well.
Pete

[NateWr]

Thanks Pete, that's useful feedback. I have in mind precisely the use-case of a section that has "ended". For example, a journal that once had a "Notes from the field" section but no longer publishes into it. Aside from disabling submissions they still want people to be able to search and browse it (when we support browsing by section).

I think that this is going to be the most common use case. But I can see the cases that you describe also being common enough. I guess the trick is to find language that covers the majority of use cases but is still specific enough to be descriptive for end users.

Perhaps we can describe it as an "Inactive Section" and when the user is confirming an action use the phrase "Deactivate" a section. In the form, the checkbox could use language that covers both. "Deactivate this section and do not accept submissions to it". In the database the column would then be is_inactive.

We'll need to think about how this is displayed on the frontend, if and when we implement browsing by section in core. I think there we'll find a real conflict between cases of archived sections and upcoming sections. But I guess that's for another day.

[PeterfordUP]

Hi @NateWr, this works for us. We're going to implement this and then create a pull request for the feature. Thanks

[NateWr]

Thanks for the PRs @salmanm2003! I'm having a little bit of trouble testing them against the latest master branch. It seems like maybe you have rebased/updated your OJS branch more recently than your pkp-lib branch.

In SectionGridHandler there's a call to SubEditorsDAO::getBySubmissionGroupId(). This reflects some changes done recently, but it looks like the SubEditorsDAO class doesn't have this method in your branch of pkp-lib. I found the same problem with a call to \APP\Services\UserQueryBuilder which was recently removed in favor of \PKP\Services\UserQueryBuilder.

I think you'll just need to do a fresh rebase against the latest master in OJS and pkp-lib to sort these issues out. I can then check out your branch, do some testing to see how it works, and provide a more comprehensive code review. 👍

[NateWr]

(One particular hiccup you'll run into with the rebase is that we just merged some big changes to our database schema management: #2493 (comment). Where you add the database column will need to change but don't worry about this for now. I can work around that for my test and we'll get it sorted before merge.)

[salmanm2003]

Hi @NateWr,
Thanks for checking the PR.
As you mentioned above, the fork been synced with upstream/master for both OJS and pkp-lib.
Please let me know if any further changes needed to be done.

[NateWr]

👍 Good work @salmanm2003! This is looking really nice. I've left comments on the pull requests with some changes -- mostly changes for language and coding conventions.

In addition to the line-by-line review, here are some additional comments:

1. You'll need to rebase again. Sorry about that, we've just begun merging some big things for 3.3 into the master branch so it's kind of a painful moment to be merging code. Should settle down soon.

2. When submissions are disabled at the journal level, let's remove the "New Submissions" button that appears in the submissions list panel.

3. We'll need to disable submissions in the REST API when they are disabled for the journal. I think you can add a conditional check at https://github.com/pkp/pkp-lib/blob/master/api/v1/submissions/PKPSubmissionHandler.inc.php#L314 and return a 403 response with the author.submit.notAccepting message.

4. To ensure that submissions aren't created for deactivated sections in places other than the submission form, we'll need to add a check to PKPSubmissionService::validate(). You can use if ($action === VALIDATE_ACTION_ADD) to only apply the validation check for new submissions (so that existing submissions can be changed to a deactivated section if needed). This raises questions about under what conditions it should be possible to create a submission for a deactivated section. My sense is never. This may be something that needs to be discussed with @PeterfordUP.

5. The PkpSubmissionSubmitStep1Form should still have validation checks to prevent submission in case the user finds a way to the form. A good way to check is to get yourself midway through submitting a form, then disable submissions at the journal or section level, and see if you can still submit. You shouldn't be able to.

6. A deactivated section still appears as an option under Publication settings. Do we want to allow assigning a submission to a deactivated section? This is maybe somethinig to be discussed with @PeterfordUP. Either way, IssueEntryForm should either not include deactivated sections in its options or it should indicate deactivated sections. If including deactivated sections, indicate them using an <optgroup> in the select field.

7. Finally, once this is all good for OJS, we'll need PRs for OMP and OPS. Usually it makes sense to finalize an OJS pull request and then work on OMP and OPS. But I guess we haven't discussed this yet with your team. I'm happy to give some guidance to help you apply these changes to OMP/OPS. We should be able to get most of the work into pkp-lib so that there isn't too much that needs doing in the other applications.

[PeterfordUP]

Hi @NateWr and (@salmanm2003 ),

In response to the two mentions:
Point 4 - from a user perspective, it should be possible to create a new submission in an inactive section. However, this should be done by journal editors and managers only, i.e. only from within the dashboard, and with editor or manager permissions. Common examples would be adding a final editorial article to a closing section after the 'public' submissions have been closed, and adding an introduction, before public submissions have been opened.
Point 6 - yes, it should be possible to assign submissions to an inactive section. For similar reasons to the above.

Hope this helps,
P

[NateWr]

Thanks, I'm happy for it to work that way in both cases. 👍

[NateWr]

Thanks @salmanm2003! The changes following code review look great with a careful attention to detail. Much appreciated! 👍 Based on our Slack discussion and the points raised previously, I think we're almost there. The following is still outstanding:

1. Minor changes in recent code review comments.

2. In a previous comment I had suggested that you split the list of sections under Submission > Publication > Issue into two groups using <optgroup>. I can see that's going to be difficult given the limitations of the Form UI components. Instead, can you indicate inactive sections in the name of each option, such as "Reviews (Inactive)".

3. Remove the "New Submissions" button in the submissions list when they are disabled for the entire context.

4. OMP/OPS

[salmanm2003]

Hi @NateWr,
Thanks for checking and commenting this.

1. The new changes been made and ready to be reviewed.
2. "Inactive" been added to the inactive sections in publication sections list.
3. "New Submissions" button has now the feature to be removed when 'disable submissions' is on (please check the PR for ui-library).
4. "Enable submissions" been changed to "Disable submissions".
5. Had to change SettingsPage.vue to add space between the notification and the content on submissions list page.
6. Before start working on OMP/OPS it would be helpful to discuss it with the team first.

[NateWr]

Thanks @salmanm2003, that looks really good! I only had a couple more very minor comments.

In addition, I'm getting an error when I edit a section to deactivate it and there is only one active section. Steps to reproduce:

1. Create three sections.
2. Deactivate two of them with the checkbox toggle.
3. Open the edit form of one of the deactivated sections and try to save it without any changes (the deactivate checkbox should be checked).
4. See error that at least one section must be active, even though one is.

I noticed that this is not reproducible if more than one section is active, so it's probably just an off-by-one error.

Otherwise I think we're ready to go. Reach out to me on slack and we can schedule a call to talk through the OMP/OPS steps.

[salmanm2003]

Thanks @NateWr for pointing out this issue.

• I have fixed the bug and should be working properly now.
• All minor changes been done and ready to be reviewed.
• I have noticed an OJS error, not sure if you aware of:
  Type: Error Message: Call to a member function getData() on null File: /var/www/html/lib/pkp/classes/submission/PKPSubmission.inc.php Line: 54.
• and a warning in PHP Warning: array_shift() expects parameter 1 to be array, object given in /var/www/html/lib/pkp/classes/core/PKPRouter.inc.php on line 481

[salmanm2003]

Here is the PR for OMP:
pkp/omp#851

[salmanm2003]

Please check all the PRs here:

• pkp-lib: #5702 Ability to disable submissions in OJS3  #5966
• ui-library: pkp/pkp-lib#5702 Ability to disable submissions in OJS3 ui-library#106
• OJS: #5702 Ability to disable submissions in OJS3 ojs#2793
• OMP: pkp/pkp-lib#5702 Ability to disable submissions in OMP omp#851
• OPS: pkp/pkp-lib#5702 Ability to disable submissions in OPS ops#56

[NateWr]

All PRs have been merged. 🎉 Thanks for your careful collaboration on this @PeterfordUP and for your patience shepherding this change through the full code review and test process @salmanm2003!

@amandastevens this will effect documentation. From v3.3 a journal will be able to disable submissions for the whole journal, or disable submissions to a specific section (for example, to archive a section or to deactivate it).