Move some properties from Publication to Submission

[NateWr]

Describe the problem you would like to solve
When versioning was implemented in 3.2, several properties were moved from the Submission entity to the Publication entity. This allowed the properties to have different values for each version. For example, two versions of the same submission can be assigned to different sections, categories and issues. These properties were moved to the Publication entity so that emerging forms of publishing (ahead-of-print, accepted version, and preprints) might be supported through versioned submissions.

However, this has proved to be complicated for most publishing requirements. Modifying metadata like section and issue assignments between versions is not well supported through our OAI interface or in downstream consumers like Crossref.

Also, since 3.2 was released, various forms of pre-publication have not made much use of the versioning system. Preprints are cultivated in separate platforms before coming to OJS. And when journals publish ahead-of-print or accepted version articles, modifying the section or issue between versions causes the problems described above.

Describe the solution you would like to see
Move these properties back to the Submission entity. I would suggest moving the following properties:

Property	Reason
sectionId	A submission that moves sections between versions causes problems for metadata consumers and does not follow our conventional model whereby a section represents a publication type (ie - article, review).
categoryIds	This is only used for organizing content on the frontend, and changing it between versions complicates the browsing structure -- for example, how to show an article summary with only the version that is in the category.
urlPath	Changing this between versions causes lots of problems with routing in the ArticleHandler. It's not used anywhere else so we should ensure it is as simple as possible.
coverImage	This is only used for organizing content on the frontend, so let's keep it simple. We don't use anything but the current publication's cover image anyway.
issueId	A submission that changes issues between versions causes problems for metadata consumers.
accessStatus	This is linked to issueId so should be a property of the entity that gets issueId.
seriesId / seriesPosition	See sectionId above.
hideAuthor	I believe this is unused, but where it is intended to be used is at the submission level.

Additional comments, code samples, or screenshots
@ajnyga I think that this may effect the forthcoming plugin. Can you comment on this further?

@ajnyga and @alexxxmendonca currently OPS includes relationStatus and vorDoi at the Publication level. Does OPS need to be able to associate each version of a preprint with a different "Relation"? Or do all versions of one preprint point to the same Version of Record?

[ajnyga]

Thanks, I will think about this. From the top of my head Forthcoming is not going to be a problem. There the critical part is that you can assign the same submission to several issues. There was some small clitch there that we talked about last year, but do not remember now what. You probably are thinking about that.

Edit: ok so missed the issueId... Yeah, this will definitely break the Forthcoming plugin. Maybe we could have that in the core when this change happens? I mean the possibility to publish an article without assigning it to an issue?

[NateWr]

If I did this now, while I'm building out the submissions API, then it will go into 3.4 and I won't have time to support forthcoming. But I agree that forthcoming should be handled in a better way than assigning it to a fake issue.

I think the key code is at IssueAction::allowedPrePublicationAccess() and these lines in ArticleHandler:

https://github.com/pkp/ojs/blob/f517aefe509c37b2d15f2072b04809281de517a0/pages/article/ArticleHandler.inc.php#L115

We could put checks into a more generic function, like ArticleHandler::canView(), with a hook. Would that allow something like a Forthcoming plugin to make a submission viewable even when it's not assigned to an issue or even without a STATUS_PUBLISHED? That would solve the metadata problems with issue assignment...

[NateWr]

It looks like there's another check:

https://github.com/pkp/ojs/blob/f517aefe509c37b2d15f2072b04809281de517a0/pages/article/ArticleHandler.inc.php#L147-L149

[ajnyga]

Another big issue has been DOI registration. In earlier versions you can only register a DOI if the article is published in an issue.

I totally agree that the "fake issue" approach is not good, I hate "cheating" when it comes to metadata

[ajnyga]

I can try to make a list of things that are obstacles for a better Forthcoming plugin.

[NateWr]

Yes, please, a lists would be great!