genericize article delete - expect the article zip filename to match the doi suffix, rather than removing the string "journal"

ArticleUtil?.delete is currently using the DOI xml file as the base of the zip file (e.g. "info_doi_10_1371_journal_pctr_0010039.xml" should move "pcbi.1000039.zip". The new filename for processed files has a "proc." prefix (e.g. "proc.pcbi.1000039.zip").

This function needs to be extended to handle both filenames and/or detect the zip file that exists and delete that file.

This function has a hardcoded substring associated to the PLoS DOI "10.1371":

String fname = article.substring(25) + ".zip";

What happens if another pubApp needs a different length DOI number?!?

(In [5323]) fixes #891, when moving files, be more flexible in Article.zip file name

Milestone pubApp_0.8.2.2 deleted

this bug has regressed in 0.9

r5323 was never merged into head, but I don't it think it's necessary either. Since no file renaming happens currently in head (i.e. we only move files from one directory to another), I don't see why this should not be working for all article types.

Please provide a sample article that exhibits this problem.

this happens with any article that doesn't follow the normal plos article naming conventions (ie pone.1234567.zip, corresponding to a 10.1371/journal.pone.1234567 doi)

our issue image articles are named like image.pone.v01.i01.zip, corresponding to a 10.1371/image.pone.v01.i01 doi.

i'm not sure why you can't see the problem here, but i'll upload an example file.

this is a pretty large example of plos-specific code - we seem to be requiring that the article zip filename is a suffix of the doi, AND that the string "journals." is appended to the doi, which is really silly.

in the past, we brought up this problem in the context of prepare-sip and were told that prepare-sip was plos specific by design and we should create alternate methods to prepare if we had non-standard dois for any article.

now we have the same problem with the admin pages.

would it really be that hard to decouple the filename from the doi in both prepare-sip AND the admin pages?

Thanks for the zip. I see the problem: it's the ambra.services.documentManagement.documentPrefix that contains the 'journal' and is messing things up.

Re decoupling things, yes, but the problem with delete is that we have to somehow guess what file originally contained the article. Yes, we could in theory open up all 2000 files in the ingested directory and search each one whether it contains the article, but I'm sure you won't be pleased with the wait time. So, instead the app tries to guess ("reverse compute") the filename from the article name, and this is where the naming conventions come into play (this problem does not exist on the ingest side of course, just for delete). I now understand the hack in r5323 a bit better, and while it sorta worked for this case it was still prone to failure if names were sufficiently different.

One solution may be to put a marker file in the ingested directory that is named like the uri of the article and that contains the name of the sip file that the article came from.

maybe it would be simpler to require the article zip to be named after the portion of the doi following the slash?

that way there's no config issue and plos would be required to rename their article zips to eg. journal.pone.1234567.zip which would be very easy to do.

otherwise we need to add complexity somehow, either by storing the doi->filename relationship somewhere as you suggest, or making config more complicated...