It should not be possible to add a galley to a published version

[NateWr]

The galleys grid should have the "Add Galley" button disabled when it is loaded with a published publication. This needs to be tested because it may still appear even on published publications.

Once a publication is published, the editor should have to create a new version before the galleys can be changed.

Acceptance Criteria

• As an editor or production assistant, I can add and edit a galleys in a publication before it is published.
• Once a publication has been published, I can not add or edit a galley.

[NateWr]

PRs:
pkp/ojs#2468
#5082

[amandastevens]

I tested these things and they work fine.

[openacademia]

Sorry for jumping into this closed thread. We have had several journals contact us and ask for XML conversions, i.e. they send us the published PDFs which our typesetter converts to XMLs. We help upload the XMLs alongside the already published PDFs. Will this no longer be possible? I also see a potential problem when using the Quick Submit Plugin to upload journal archives. In order to be able to add the published dates in the QS process, one needs to assign the papers to a published issue. Would we not be able to add additional galleys after that, if needed?

Thanks and best wishes,
Emma

[NateWr]

Hi Emma,

There are two options if you post the XML after a submission is already published. You can create a new version, add the XML galley, and publish that version. Or there is an "unpublish" button so you can unpublish that version, add your XML, and republish it. We discourage the unpublish flow in most cases but its there for editorial circumstances where you feel its worth discarding the public publishing history.

Would you mind documenting your use-case for QuickSubmit date setting in this issue? With the new publishing workflow, it should be easier to set the publish date independently of the issue. But the QuickSubmit plugin's workflow may need to take special account of this circumstance.

[openacademia]

Hmm, it sounds like we will no longer be able to provide XML conversions for archives as a service. Both options would be too much of a hassle* and (I suppose) would lead to either loss of editorial history (option1) or loss of download/usage stats (option2). Also, option1 would generate a new DOI and it would snowball into kind of a nightmare. Offering XML conversions is just a minor component of the services we provide, so not the end of the world if we have to stop doing that. May I ask what the idea behind this restriction is? Will we still be able to replace the files post-publication? We are very mindful of doing that, of course, but there are cases were it is necessary to fix something in one of the files (a link that should be clickable but isn't, for example). Will that still be possible without unpublishing/publishing?

*it is not a hassle if we are talking ONE paper, but if we are to supply XML files for entire volumes it becomes overwhelming.

I will add my comment about the QS thing in the other thread.

[NateWr]

Neither option should lead to loss of editorial history or download/usage stats. The publishing step in the workflow has been changed significantly and it may not be as much of a hassle as you're anticipating. I know that Publishing Services is doing some testing on 3.2 at the moment. It might be a good idea to reach out to them to discuss your particular use case in more detail and maybe see if you can play around with their test instance to see for yourself how it impacts your XML service workflow.

[openacademia]

Thanks Nate, I might do that.

I probably misunderstood option 1, "creating a new version and publishing that one". I thought you meant creating a new submission URL altogether and adding the PDF and XML to that new version. That would for sure nullify any editorial history or usage stats AND generate a new submission ID, new DOI etc.

About the Quick Submit issue I raised, I realise now that I can select a Future issue in order to be able to add Published Date and Page Numbers directly on the QS form, so it is not a problem after all. It is just if we select "Unpublished" that Published Dates and Page Numbers do not appear which makes perfect sense! =)