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 File logging still occurs when deleting a submission or context #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: Allow bulk deletion of Incomplete Submissions #10258. @asmecher @ewhanson @jonasraoni

UI library (main)
Please see demo here

• pr: Allow bulk deletion of Incomplete Submissions ui-library#390. @jardakotesovec

submodule updates

• ojs: submodule update ojs#4387
• omp: submodule update omp#1665
• ops: submodule update ops#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 (#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.

[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.

[jardakotesovec]

ui-library PR for new dashboard - pkp/ui-library#454
pkp-lib with some additional locales on top of @taslangraham PR - #10655

@Devika008 Can you check it out on https://jarda.testing.publicknowledgeproject.org/ojs/ ? Currently it works for the admins. For authors it needs API adjustments.

@taslangraham Could you look into updating the endpoint so it would be also possible to delete incomplete submissions by their author? Feel free to cherry-pick my commit with additional locales to your PR. We can clean up the locale keys once we get feedback from Devika and Israel.

@israelcefrin Hi Israel, tagging you as well in case you have some suggestions on improving the accessibility of this feature. Please check out the notes below as well.

Some notes:

Logic

• Original intention was to allow bulk delete of incomplete submissions to admin, which would come from spammers. Given that we are not carrying over the 'Delete' button from 3.4 submission listing to the new one, we also decided to make it available for authors to delete theirs incomplete submissions as replacement.
• Additional use case which was covered by the Delete button in 3.4 submission listing, which allows to delete Declined submission to editors will be now awailable in workflow page - it will be added as part of existing issue.

UI

• Delete Incomplete Submission button is present for admin on editorial dashboard and on author dashboard to be used by authors
• Delete Incomplete Submission button is disabled if there is no incomplete submission that could be deleted in current listing
• Delete Incomplete Submission once there is incomplete submission that could be deleted, its using secondary styling - and once click on it its using 'active button' styling to indicate that this functionality is on - and the checkboxes shows up
• Delete Incomplete Submission change to warnable styling once some submission is selected and can be used to execute the deleation
• I used disabled checkboxes for submissions that can't be deleted, as I think this make it bit easier for SR to orient themself rather than empty cell
• From accessibility point of view - the tricky is that that we use one button first as switcher and than as normal button. Improvement probably should be that when it behaves as switcher - it should be coded as switcher as well. Or maybe we could figure out to have separately switcher and the button to execute delelation - that would probably be improvement for SR.
• Column with checkboxes has SR label: Select incomplete submissions to be deleted., hidden to normal users
• Checkboxes are connected with the submission title via aria-described-by - which seems to work quite nicely when testing with screen reader so its clear that its on the checkbox on which submission

Here is screenshot so its clear what part of UI we talking about:

[taslangraham]

Nice work @jardakotesovec! I'll take a look at updating the endpoint to support Authors today.

[taslangraham]

I've updated the original PR to support Authors deleting their incomplete submissions

[israelcefrin]

Hello @jardakotesovec

From accessibility point of view - the tricky is that that we use one button first as switcher and than as normal button. Improvement probably should be that when it behaves as switcher - it should be coded as a switcher as well. Or maybe we could figure out to have separately switcher and the button to execute delelation - that would probably be an improvement for SR.

If you follow the first option you mentioned, then you will need to alert the users through some aria-live region alert to let them know that the element has changed its function. However, it might cause some confusion. I think that the second option, separating the switcher from the button, would be an easier solution and approach for those SR users. It would even ease the burden to people with cognitive disability because you wouldn't have the option to alert them that an element changed its function unless you trigger an alert (which would become annoying and intrusive each time the element changes).

Checkboxes are connected with the submission title via aria-described-by - which seems to work quite nicely when testing with screen reader so its clear that its on the checkbox on which submission

We now have access to JAWS and NVDA screen readers and can also test it. Could you please add me to the installation that is running this code? I can review it using these windows based screen readers along side VoiceOver.

[asmecher]

Related: #4348

[jardakotesovec]

After discussion with Devika and Alec, here are some tweaks to work on:

1. Allowing Journal Manager to also bulk delete incomplete submissions, so they don't have to communicate submissions to be deleted always with admin.
   @taslangraham Could you make this adjustment on the API please?

2. To address some of the UI concerns with double role of the Delete Incomplete Submissions button - here are the changes, which I will work on. I will not show the 3dots unless there is some incomplete submission. Other option would be to show 3 dots, but show the delete submission action as disabled there. Let me know what you think is better.

3. Will make the disabled checkboxes screen reader only, so its cleaner UI for users who are not using screen reader.

[taslangraham]

1. Allowing Journal Manager to also bulk delete incomplete submissions, so they don't have to communicate submissions to be deleted always with admin.
   @taslangraham Could you make this adjustment on the API please?

I've updated the API to allow managers to delete incomplete submissions

[taslangraham]

2. To address some of the UI concerns with double role of the Delete Incomplete Submissions button - here are the changes, which I will work on. I will not show the 3dots unless there is some incomplete submission. Other option would be to show 3 dots, but show the delete submission action as disabled there. Let me know what you think is better.

My thoughts - I prefer the second option because it's more consistent. Keeping the three dots always visible makes it easier for users to understand. If the dots appear only sometimes, users might take longer to figure out why. With the dots always there, they'll click it and see that the delete submission action is enabled/disabled. So in cases where they do have incomplete submissions, they'll know exactly where to go if they'd like to delete said submissions

[jardakotesovec]

@taslangraham Yeah.. I was also thinking similar thing when I was writing down the second option :-). Will let @Devika008 decide whether it's worth adjusting.

[Devika008]

The second option is what we should go with! Taslan is right that the users would like to see consistency and not have to wonder why something is disappearing

[jardakotesovec]

Oki, updated.

ui-library pr: pkp/ui-library#461

Locale keys that are used:

admin.submissions.incomplete.bulkDelete.confirm
admin.submissions.incomplete.bulkDelete.body
admin.submissions.incomplete.bulkDelete.column.description
admin.submissions.incomplete.bulkDelete.button

@taslangraham Please just check whether there are some additional locale keys that could be removed in pkp-lib and let me know once your PR is ready to be merged.