Automatic v2 PoA delivery

[gnott]

The ability to supply a version 2 of a PoA XML is now supported. It requires some manual steps by production team, and direct editing of XML files. The files flow to the publication system, PubMed and Crossref using the correct pub date.

It is possible to further automate the supply of version 2 PoA in the following way:

• Production team has edited the content of the article in the proofing system, and requires to be published as a v2
• Production team initiates the PoA files to be delivered to the bucket again
• Check to see if the article has already been published before. If it hasn't, then it can continue PackagePOA the files as a version 1 and upload the contents to the outbox
• If the article has already been published, then determine from the bucket history whether it is a v2, or v3, etc.
• Change the XML filename to include "v2" or "v3" etc. as is done manually now by the production team
• Add the actual publication date to the XML file
• Change the article ID / publisher ID value in the XML file
• The files are copied to the outbox, awaiting the PublishPOA workflow

The above basically reproduces what the production team must do manually in order to get a v2 PoA into the production system.

[sparker88]

Depending on the issues leading to a v2, there is a chance that we also have to supply an edited Data Supplement ZIP along with the v2 files. These will usually be delivered along with PoA files as part of the PackagePOA process, yet will require a different naming convention at v2, with the "v2" being entered slightly earlier:

elife_poa_e00092v2_ds.zip

In the event that we have to manually edit a Data Supplement ZIP, the manifest.xml file must also be updated to reflect the v2, e.g:

<resource type="publisher-id">00092v2</resource>

If the DS supplement doesn't need changing but gets redelivered, it will have to be removed from the Highwire system - but the bot would have no way of knowing this.