Create a way to "close out" publications stuck in Wrong File Version

[anaelizabethenriquez]

Currently, 611 of 1196 publications in the AI OA Workflow are in the "Wrong File Version" bucket. It's turning out to be quite difficult to get publications out of this bucket. The response rate to our emails is low. There are more than 400 publications in the bucket that we've sent emails for already. #996 is a feature aimed at that problem. But we know from other emails we send (OA reminder emails, ScholarSphere curation emails) that the response rate is not going to be 100%.

We need to decide what to do with publications for which we send repeated emails and the researcher does not reply. Basically we have three options:

1. leave them in the bucket, perhaps with improved sorting/filtering
2. put them in a new bucket of their own
3. remove them from the workflow (and remove the files from RMD and/or Activity Insight?)

Features to consider regardless of option

• Add a count of how many times we've sent a Wrong Version email about the publication. Display this on Wrong Version bucket or otherwise enable admins to sort by it.

Option 1

• Enable the user to sort and filter the publications in this bucket. E.g., hide (or sort to the bottom) publications and/or researchers for which we've sent emails ever or within a certain time frame.

Option 2

• Split this bucket into two buckets, one for publications that we've already reviewed and sent a "wrong version" email for and one for all other files. For the "already reviewed" bucket, send an automatic email every six months with the list of files that we have the wrong version for. Consider consolidating this into the regular OA reminder emails. (Question: If a researcher replaces the file without telling us, and it goes through automated version review, would it be possible for it to slip back into the "already reviewed" bucket? We probably wouldn't want this.)

Option 3

• Based on the file upload date and/or the number of times we've sent a Wrong Version email, remove files from the workflow. (This may not be necessary if we improve the sorting on this bucket.) What this should look like is not clear -- would we want to keep the files in Activity Insight? Would we want to send the author a final email with the file attached, but delete the file from RMD and Activity Insight?
• For files that we've sent a Wrong Version email about, check to see if the researcher is still at PSU. If not, wait for a set period of time to see if we get an email response, and then remove the files. Not sure if any emails are being returned as undeliverable, but we'd certainly want to do something about articles associated with those.

[ajkiessl]

@anaelizabethenriquez From the development side, I think the simplest solution here is to add a separate "already reviewed" bucket (Option 2) for these to go to after an email has been sent. Adding another bucket with one added criteria and another task for sending those emails would be pretty simple. Adding filtering and sorting (or even search) functionality is definitely possible, though, if that's preferred. Option 3 could still be implemented later on if we decide we want an automated way to get rid of these files. If we do this, we should probably keep the record in our database, but flag it as "removed" or something. We could still delete the file, but keep the record so we won't have to worry about it getting imported again. There may be a way to delete files in Activity Insight through the API, but I'm not sure.

If a researcher replaces the file without telling us, and it goes through automated version review, would it be possible for it to slip back into the "already reviewed" bucket? We probably wouldn't want this.

Since the criteria for landing in the "already reviewed" bucket would include having an email sent, it wouldn't end up in this bucket automatically. However, it would end up there if an email is triggered by an admin, which would hopefully involve a review. If this isn't what we'd want to happen, what would we want?

We don't track how many of these emails we've sent out right now, but we can implement something to track that number and display it.