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.

[NateWr]

I think this is a holdover from the way that things worked in stable-3_3_0. There the publication date was set in lib/pkp:

https://github.com/pkp/pkp-lib/blob/stable-3_3_0/classes/services/PKPPublicationService.inc.php#L555-L557

Then a hook was called:

https://github.com/pkp/pkp-lib/blob/stable-3_3_0/classes/services/PKPPublicationService.inc.php#L581

And in OJS, a callback was registered to "reset" the date published based on the application logic (issues):

https://github.com/pkp/ojs/blob/stable-3_3_0/classes/services/PublicationService.inc.php#L252-L256

I think your proposed logic is broadly correct. The one difference is that we shouldn't call $publication->setData('datePublished', null). We should never overwrite a datePublished value if one has been manually entered in for the publication. A use-case for this is importing back issues from continuous publishing, where each article has its own published date but will be put into a future issue before the issue is published all at once.

So I would express the desired logic in pseudo-code like this:

if (!issue) {
    publication->setPublishedDate(now)
} elseif (issue && issue-published) {
    publication->setPublishedDate(issue-published-date)
} else {
    // leave the publication alone
}

If it is scheduled in a future issue, the datePublished may exist or not. Then when the issue is published, it should set the published date of its articles only for articles that don't already have a date.

[ajnyga]

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

pr's to allow setting issue published date when creating a new issue. Also includes a small tweak to DatePicker widget allowing easier access to older dates (see month & year menu option https://jqueryui.com/datepicker/#dropdown-month-year)

[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!