Can't set the publication date of an issue before it is published

[AhemNason]

Describe the problem you would like to solve
It is not possible to create a publication date for an issue before it is published. This creates problems when using QuickSubmit to upload back content because it is not possible to set a submission's publication date in QuickSubmit (see #5418).

Describe the solution you'd like
It should be possible to set the published date of an issue before it is published, in order to support uploading back content. When the issue is published, it's publication date should not be overridden and it should be used to set the publication date of any assigned submissions without a date.

Who is asking for this feature?
Journal managers and assistants performing migrations of back content.

Additional information
Just off the top I'd like to note that this came to me specifically in relation to the QuickSubmit plugin but I've determined that it doesn't actually matter how you've uploaded the file. There are, I'd argue, sensible use cases for additional date metadata within QuickSubmit (or elsewhere) that will not be overwritten or ignored on publication of an issue. Those include:

• submission date (historical... not within OJS)
• article publication date (which OJS and QuickSubmit does have, but is overwritten by issue-level publication date)
• issue publication date

So the problem is as follows.

Let's say I'm uploading an older issue of my journal to OJS from before my adoption of the platform. We'll say the issue was originally published on the first of January, 2010 (2010-01-01). I create a "future issue" in which to assign these articles I'll be uploading. Issue metadata for a future issue does not include a publication date with the volume, issue, and year metadata.

I hop over to QuickSubmit and start working on all my uploads. When I get to the portion of QuickSubmit where I flag the status of the work, I'll select "published" and I choose which issue it was published in. I select my future issue. A date field appears. I can input when the article was published. I do this for the whole issue I'm uploading so I can preview it and make any changes before making it public.

I publish it, and I see that all the dates I entered are gone! The dates have all been overwritten by today's date, the day that I made a back issue live. I've written a guide for folks on how to avoid this (https://www.notion.so/ahemnason/Uploading-Back-Issues-in-OJS-that-Respect-Publication-Dates-2cd0fa628fe94f0888ed630c5cf8b6d5), but TL;DR the only way to avoid it is to publish your empty back issue, edit it's publication date after you hit publish, and then add your articles to it.

This doesn't change the fact that your submission dates will be wrong, but at least your publication dates will be right.

I'd make a general recommendation that "submission date" and "publication date" be accessible fields for users to input values to as metadata when needed. There are a few down-stream effects of these publication date issues. If someone doesn't catch it, citations for this back-content will be way off. Also, registration agencies like Crossref charge different fees based on the age of the content uploaded. If a journal is working on a long backrun, this could be the difference between a $1 USD fee per article deposited and a $0.15 USD fee per article deposited.

The only way to remedy this mistake with the OJS UI for users who have done this is to, article-by-article, unpublish the work, add the publication date to the "issue" section of the production workflow, and republish it.

Oh, and I confirm all this behaviour in 3.3.0.6

[NateWr]

Thanks @AhemNason. I don't think it will be too difficult to do this. Here's a list of things that need to be considered:

• Add publication date field to future issues. It should be clear that this is not usually set. Maybe the field needs a warning like "Leave this empty and it will be set automatically when the issue is publlished."
• When an issue is published, the date is assigned to submissions automatically if they don't have a previous date assigned. In such cases, use the issue publication date should be used if it has been set.

[AhemNason]

For your first point I think you mean...

Add publication date field to back issues future issues.

[AhemNason]

Another option could be an option to push issue-level publication dates to all the articles within it. So, at the very least, if you have to fix a back issue, you can just update all the article-level metadata to match issue-level metadata.

[NateWr]

Another option could be an option to push issue-level publication dates to all the articles within it.

We should avoid modifying article metadata after it is published.

[ajnyga]

ojs: pkp/ojs#3500

When an issue is published, the date is assigned to submissions automatically if they don't have a previous date assigned. In such cases, use the issue publication date should be used if it has been set.

I am not touching article pub dates here at all. Is this something we want to handle here as well?

[asmecher]

@NateWr, could you review this? (@ajnyga, Nate is away for a bit so it won't be immediate!)

[ajnyga]

Noticed that I did not add the editor.issues.datePublished.notPublished.description translation to the pr.

That is basically the "Leave this empty and it will be set automatically when the issue is published." notification mentioned above. Let me know if you want something else there.

[NateWr]

Thanks @ajnyga, I left a couple comments.

I am not touching article pub dates here at all. Is this something we want to handle here as well?

Can you try to reproduce the problem that @AhemNason described in the original issue? I had a quick look through the code and didn't see anything that sets the submission's datePublished based on the issue. But if you can reproduce it with your changes then we want to handle that too.

[ajnyga]

1. New issue, not published, set pubDate to 2022-09-01

2. New article with quicksubmit, choose the new issue, set article Pubdate to 2022-09-10

3. After adding the article go to see article details -> The article pubdate is NULL!
   I also checked the db for this, publication date_published is NULL
   The publication status is scheduled like it should be

4. Publish the issue -> The article pubdate is set to current date!

So yes, something fishy going on here and these changes do not fix it.

[ajnyga]

When the issue is published, this is called: https://github.com/pkp/ojs/blob/main/classes/controllers/grid/issues/IssueGridHandler.php#L592

With the set pubDate being just NULL in these cases, I guess you just end up setting it to the current date.

[NateWr]

It seems like what's outlined in this comment is still relevant: #7165 (comment). Does something more need to be done?

[ajnyga]

I think quicksubmit too needs fixing. It seems that it does not respect the publication date given by the user at all

[ajnyga]

I think we need to think about the whole palette before doing any more changes.

[ajnyga]

This is probably the source of the problem: https://github.com/pkp/ojs/blob/main/classes/publication/Repository.php#L157-L166

  protected function setStatusOnPublish(Publication $publication)
   {
       // A publication may be scheduled in a future issue. In such cases,
       // the `datePublished` should remain empty and the status should be set to
       // scheduled.
       //
       // If there is no assigned issue, the journal may be using a continuous
       // publishing model in which articles are published right away.
       $issue = Repo::issue()->get($publication->getData('issueId'));
       if ($issue && !$issue->getData('published')) {
           $publication->setData('datePublished', null);
           $publication->setData('status', Submission::STATUS_SCHEDULED);
       } else {
           $publication->setData('status', Submission::STATUS_PUBLISHED);
           if (!$publication->getData('datePublished')) {
               $publication->setData('datePublished', Core::getCurrentDate());
           }
       }
   }

If the issue is not published when you add new articles with quicksubmit, that will set the article pubdate to NULL.

[NateWr]

🤔 if the issue is not published, the quicksubmit plugin shouldn't be trying to publish a publication, right?

[ajnyga]

Quicksubmit has two options:

1. This is not published, meaning that the submission in sent to production stage
2. This is published, meaning that you need to choose an issue (future or published) and set a pubDate for the article

If you choose 2, then this happens https://github.com/pkp/quickSubmit/blob/main/QuickSubmitForm.inc.php#L378

[ajnyga]

I would be inclined to do something like this:

        // Case 1: issue not published and a future issue - pubDate for articles set when issue published
        if ($issue && !$issue->getData('published') && !$issue->getData('datePublished')) {
            $publication->setData('datePublished', null);
            $publication->setData('status', Submission::STATUS_SCHEDULED);
        } 

        // Case 2: issue not published and a backissue - pubDate for articles set according to the issue pubDate if no article pubDate exists
        else if ($issue && !$issue->getData('published') && $issue->getData('datePublished')) {
            if (!$publication->getData('datePublished')) {
                $publication->setData('datePublished', $issue->getData('datePublished'));
            }
            $publication->setData('status', Submission::STATUS_SCHEDULED);
        }

        // Case 3: issue is published already - pubDate of articles set according to the current date (continuous publishing)
        else {
            $publication->setData('status', Submission::STATUS_PUBLISHED);
            if (!$publication->getData('datePublished')) {
                $publication->setData('datePublished', Core::getCurrentDate());
            }
        }

[ajnyga]

So publication::publish and setStatusOnPublish is in most cases called twice for each submission?
First when you schedule the submission and again when you publish the issue?

So with the old code https://github.com/pkp/ojs/blob/main/classes/publication/Repository.php#L157-L166

When you scheduled the submission it would always set datePublished to NULL. Both with quicksubmit and with the usual workflow. Because when you schedule, you never have a published issue.

Then when you went on to publish the issue, you would always get the articles dates set to the current date because datePublished in all cases is NULL https://github.com/pkp/ojs/blob/main/classes/publication/Repository.php#L163-L165

Only if the issue is already published, the datePublished given to the article is respected.

[ajnyga]

@asmecher this fairly important small feature did not get into OJS 3.4. I have rebased everything and there is an old code review from Nate that I have taken into account. Could you/someone else recheck this and maybe do a merge?

OJS: pkp/ojs#3500
pkp-lib: #8505

This will help journals adding back issues a lot.

[asmecher]

@defstat, could you have a look at this? Thanks!

[defstat]

@ajnyga @AhemNason @asmecher I am working on the following scenario:

1. Editor creates a future Issue defining a certain "date published" (for example "2018-03-29")
2. Editor assigns the above issue to a publication of a submission. The publication has no "date published" defined.
3. Upon publishing the issue, the publication inherits its "date published" from the Issue - Now the "date published" of the publication is "2018-03-29"
4. Editor unpublishes the issue - the "date published" of the issue resets to null (First Question)
5. Editor republishes the issue - the "date published" of the issue sets to today()
6. Editor changes the "date published" of the issue to "2021-05-19"

Steps 4, 5 and 6 leaves the "date published" of the publication "2018-03-29" (even if I unpublish the publication, so that it's metadata can be "edited")

In this scenario I am noticing the following:

1. The Editor has actively changed the "date published" of the issue to "2018-03-29". I suppose this is done only if the Editor knows that that is actually the "date published" and wants to keep it what ever actions is doing (except, of course, from changing the "date published" value). - In the scenario above, unpublishing the issue leads to the reset of his date entry.
2. The Editor actively is not setting the "date published" for the publication, intending all the publications of the related to this issue submissions to inherit the "date published" of the issue. - In the scenario above, the publications of the Issue have different "date published" from the issue.

Other than that, the other scenarios that I checked do what the issue wants to fix.

[ajnyga]

So do you think that upon unpublishing an issue, we should not reset the datePublished of the issue to NULL?

I think at some point in the conversation it was suggested that we should have an option of stamping the current issue datePublished to all the articles inside the issue. This should not be automatic so changing the the datePublished should not probably directly affect all articles, but maybe we could have an additional issue action for doing this "Reset article published dates"

[defstat]

So do you think that upon unpublishing an issue, we should not reset the datePublished of the issue to NULL?

I think at some point in the conversation it was suggested that we should have an option of stamping the current issue datePublished to all the articles inside the issue. This should not be automatic so changing the the datePublished should not probably directly affect all articles, but maybe we could have an additional issue action for doing this "Reset article published dates"

I wouldn't suggest to not reset the datePublished in general upon unpublishing. But, if the scenario I am describing needs to be considered, we could have a "lock date checkbox" or something in the form, making the datePublished field mandatory and "changing"/"regulating" the functionality of both issue publishing/unpublishing and the publication respective functionalities accordingly.

Regarding the datePublished of the publications, I am not sure if we must mess with published content - Also other cases needs to be considered if we want to go that way - for example registration services synced metadata (like Crossref as @AhemNason has already mentioned)

I am not sure statistically if such a functionality is "needed".

[ajnyga]

For Crossref and other similar services we would require some sort of "edited" flag to publications in general, not just when the published date changes. Meaning that when metadata changes in a publication, Crossref plugin will pick up the publication again and redeposit with new metadata. But this is of course not something to be dealt with here.

I think in the example you have the new code is now behaving according to the basic assumption we have made in OJS, meaning that issue date published and article date published are separate. Once the article date published is set to something, editing the issue date published does not change it. This is the case in the current code in 3.4 as well.

I am maybe not sure how you would prefer the functionality work like when you unpublish and publish an issue again with a new date?

[defstat]

Yes we agree regarding the publications datePublished

Regarding the datePublished of the publications, I am not sure if we must mess with published content

The scenario's main concern is the issue's datePublished. The editor can always change the datePublished, though, even if it is set to null after the unpublishing of the issue

[Vitaliy-1]

It would be great to store the information about date modifications somewhere, e.g., in the event_log

[bozana]

Hi all, I would have two questions:

• Why do we want to sett date_published = null when we unpublish an issue? -- Once published, the first date_published should actually not changed, no? So I think the actual date_published should be kept somewhere, but it we can allow the it to be changed.
• From this comment Can't set the publication date of an issue before it is published #7165 (comment), item 20110831 several updates to de_DE locale #3 ("Schedule publication without date in published issue = publication has issue date"): Why does not the article get the current date as date_published? I think if the article does not have a pre-defined date_published and is assigned to an already published issue it should get the current date (today) as date_published -- this is the actual truth, no?
  The same guilt for this comment Can't set the publication date of an issue before it is published #7165 (comment), this item: "New submission created through the regular workflow. Publish without preset article pubdate in an already published issue -> article has issue pubdate".
  Thanks!

[ajnyga]

Hi,

Sorry for missing your comments earlier.

Why do we want to sett date_published = null when we unpublish an issue? -- Once published, the first date_published should actually not changed, no? So I think the actual date_published should be kept somewhere, but it we can allow the it to be changed.

Are you talking about this part of the code https://github.com/pkp/ojs/blob/main/classes/controllers/grid/issues/IssueGridHandler.php#L679-L689

That is the current functionality in OJS. I am not sure why it is written that way, but it could make sense to leave the datePublished intact when unpublishing. Do you want me to add that to the pr? We have to of course check that issue's datePublished is not used as a check in the code of whether the issue is published or not.

From this comment #7165 (comment) ("Schedule publication without date in published issue = publication has issue date"): Why does not the article get the current date as date_published? I think if the article does not have a pre-defined date_published and is assigned to an already published issue it should get the current date (today) as date_published -- this is the actual truth, no?

This is mentioned also in one of the original comments:
#7165 (comment)

@AhemNason do you recall if this was one of the original requests? For me the most important fix here is that we have a transparent and solid way of adding back content. This means that we can define a date for a future issue before publishing and then when articles are added to that issue, they get the same date when the issue is published. From this point of view, I do not see any clear problem for having the logic be:

1. Schedule publication without date in unpublished issue -> publish issue = publication has issue date
2. Schedule publication with date in unpublished issue -> publish issue = publication has publication date
3. Schedule publication without date in published issue = publication has current date
4. Schedule publication with date in published issue = publication has publication date

@Vitaliy-1 which date modifications do you have in mind? Do you mean if we change the issue publishedDate of an existing issue afterwards?

Also, do we want to consider the scenario @defstat raised above. In short, if you unpublish an issue and change the issue datePublished, this does not affect the articles. Should it affect it, and if so, should there be a separate selection in the form for this? This could be done for example with an issue form selection "Match all article publication dates with the issue publication date".