Ability to bulk-delete old incomplete submissions

[pmangahis]

Describe the problem you would like to solve We've received 2 requests from hosted clients to have a multi-select option to remove incomplete submissions.

Describe the solution you'd like Currently, JMs need to delete incomplete submissions from authors and QuickSubmit plugin.

Who is asking for this feature? Journal Editors, Journal Manager

[NateWr]

Thanks @pmangahis. Can you say a little bit more about the use-case and the steps that editors are taking? I assume that editors/managers are identifying old incomplete submissions in some way before deciding what to remove. How do they determine which ones to remove? Why do they feel they need to remove them?

[pmangahis]

In one case the journal was doing a manual import from BePress using the QuickSubmit plugin. I think when there is an error during the submission process using QuickSubmit it still creates a record. They want to be able to remove duplicates.

In the other journal, it seems that the journal has multiple pages (over 10) of incomplete submissions from what I can tell were the authors created that the JM would like to remove.

[NateWr]

Thanks! I think the QuickSubmit issue is probably something that we should address at its source. With the incomplete submissions, do you know if these were done by a single malicious user or spam bot? Or had they just accumulated over many years?

[pmangahis]

I think it might be both cases for the other journal.

[carolinatanigushi]

We also have this issue on our installations.

Journals have previously let us know that there are a lot of abandoned submissions that they need to manually delete. It's an issue on our OPS installation as well, considering that out of our 357 currently active submissions, 239 have not been touched on the last six months.

[jnugent]

Just to add 0.02 to this from the systems side. We've been able to clean out incomplete submissions by using the following logic:

1. We identify old and stale incomplete submissions by looking at the submissions table and querying based on submission_progress > 0 and a date_last_activity that is older than a determined threshold with the client.
2. These submission ids are put into a text file and iterated over on the command line in a shell script and passed to the tools/deleteSubmissions.php tool.
3. In 3.3, before we can do this we need to comment out the code in the submission file service that logs file deletions because of this issue https://github.com/pkp/pkp-lib/issues/7597

But this does seem to work for us. We've a few clients that are very old and have a long history with OJS 2 and now have upwards of a thousand incomplete submissions accumulated over the years, so it's nice to be able to clean these out.

Jason

[librariam]

In addition to Jason's script suggestion above, for a use case with a smaller number of incomplete submissions - I wonder if it would make sense to bring back the old submission "Delete" button for admin accounts only (before a submission is declined)? I understand the reason for removing it for JE/JM accounts, but having an admin delete submissions quickly would be very helpful.

[Devika008]

Hello,

Here are the designs for the the issue! The considerations taken for the designs were:

• Adding a checkbox next to each incomplete submission in the submission list.
• Adding a checkbox to select all checkboxes from Step 1.
• Adding a delete button to delete all selected items.
• Adding a confirmation modal

Also I do like @librariam 's suggestion of only including this option for the admin only

3.4

On selecting a checkbox, the delete button becomes enabled

You can select and deselect all after a checkbox has been selected

This needs to be an entirely intentional action and hence an extra layer of confirmation is necessary

3.5 For the 3.5 submission table, I confirmed with Israel that placing the button before, like in Gmail, is more intuitive. To make the table more accessible, the column heading can be visually hidden but still made available to screen reader users. When using a keyboard, there will be an "on focus" state. Developers can add an aria-label or a with a class to hide it. The text to be announced by the element should be "Select/deselect the submission." I think the suggestion fits extremely well with the current proposed submission lists dashboard

A confirmation message similar to 3.4 needs to be shown here as well.

[taslangraham]

Thanks @Devika008

[taslangraham]

Ready for review.

PRs

pkp-lib (main) This introduces a new endpoint that accepts a list of submission IDs via a query param, performs the necessary validations, and deletes the corresponding submissions.

• pr: https://github.com/pkp/pkp-lib/pull/10258. @asmecher @ewhanson @jonasraoni

UI library (main) Please see demo here

• pr: https://github.com/pkp/ui-library/pull/390. @jardakotesovec

submodule updates

• ojs: https://github.com/pkp/ojs/pull/4387
• omp: https://github.com/pkp/omp/pull/1665
• ops: https://github.com/pkp/ops/pull/744

[jonasraoni]

@taslangraham I think you're tagging the wrong Erik, it should be @ewhanson 😁

[taslangraham]

@taslangraham I think you're tagging the wrong Erik, it should be @ewhanson 😁

ha! you're right. thanks

[jardakotesovec]

@taslangraham Hi Taslan, this unfortunately needs to go on hold for some time, at least the UI part.

Thing is that for version 3.5 (main branch) - the submission list panel is being replaced with new UI, which is not using ListPanel anymore (https://github.com/pkp/pkp-lib/issues/7495). At this addition can be considered once the new UI is more settled. Therefore the changes you introduced to submission list panel would work only for version 3.4 - but at this point we are not adding new functionality to 3.4 as we need to focus on finishing things off for 3.5.

Sorry about that, this is a mistake on our part.

[taslangraham]

@jardakotesovec I understand. I'm fine picking this back up when the new UI is ready

[ewhanson]

In that case I'll also hold off on reviewing things until it's ready to move forward. Feel free to ping me again once it's time, @taslangraham.