Add JAV support to backoffice

[defstat]

Describe the feature
The following changes should be addressed in this submodule:

1. DB Changes for the JAV Versioning data to be added to Publications
2. Migrations for DB tables and/or existing data migration
3. Backoffice/Repository/Classes changes for getting/setting/updating JAV version data
4. API support to expose:
   -- Get next available version numbering for submission
   -- Update JAV stage and version numbering for publication
5. Remove existing version column from publications and migrate

---

PRs
OJS: pkp/ojs#4604
OMP: pkp/omp#1978
OPS: pkp/ops#971

PKP-LIB: #10810
UI-LIBRARY: pkp/ui-library#488

[defstat]

@asmecher I have added new PRs for that, incorporating the review comments fixes of #10666.

There are some more changes that we need to consider like tests fixes and OMP, OPS changes.

Also I have added a check for publication.required.versionStage so that the publication can't be published before having a version stage assigned, but for this to work we either need to consider adding temporarily (before of the absence of the related UI support) a default stage, or temporarily remove the check.

Nevertheless, the other indented functionality is in place.

@ewhanson
There are also some changes ( in DoiListPanel, DoiListPanelOJS, DoiListPanelOMP, DoiListPanelOPS that need consideration I think, not being sure of the intended use of the following:

This line of code:

const versionNumber = publication.version;

is changed to that

const versionNumber = publication.versionDataDisplay;

The publication.version is always available and a number, but publication.versionDataDisplay is a string like undefined version (remains to be decided) or something like Version of Record 1.1

[ewhanson]

Hey @defstat, the publication.version you reference is primarily used in distinguishing the different publications versions in the table to edit the DOIs for different version. So there is a table with the DOIs for a version of a publication (with the heading of versionNumber mentioned above) followed by tables with subsequent publication versions. It is used in the same way it is used in the current submission workflow to distinguish one version from another, not necessarily to supply semantic editorial meaning. Let me know if you need any more details. It's not currently expose in OJS and OPS is the only active example where this can be seen right now.

[defstat]

@ewhanson thanks! So that means that if we now distinguish the versions by a respective string instead of an integer, the current functionality will still work as it supposed to?

[ewhanson]

@defstat, yes it should. 🤞 Though it should be tested in OPS with DOI versioning enabled to make sure. The Cypress tests there will likely need to be updated as well.

[defstat]

@asmecher the PRs are ready for another review round.

[asmecher]

@defstat, with apologies for the delay, I've added some reviews:

• [pkp-lib][main] #10669 Change Version support for publications #10810 (review)
• [OJS][main] #10669 Change Version support for publications ojs#4604 (review)

Thanks!

[defstat]

@asmecher I have resolved the review comments. The code is ready for another review. OMP, OPS porting is pending, as well as the changes for Native Import/Export plugin for the newly created source_publication_id column.

[asmecher]

Thanks, @defstat, I've added a review; there are some minor suggestions for pkp-lib, and nothing for the app repos. I think it would also be better to move the JAV terms into the pkp-lib locale files -- they don't need to be distinct for each app.