Proposal: The assignment of a submission to an issue and archiving it should be independent steps [OJS 3.2.1.1]

Dear OJS Community,

in OJS version 3.2.1.1, which we use, and apparently also in the current version 3.2.1.2, submissions can only be scheduled for publication and assigned to a future issue after all production phases have been run through and the “Production” phase has been completed. Once assigned to an issue, the submission is no longer active and is automatically moved to the “Archive”.

We would find it useful if these two steps, archiving the submission and assigning it to an issue, were independent of each other. We plan our issues a long time in advance and it would therefore be useful to be able to assign submissions to individual issues before all production phases have been completed. The submission should therefore remain active after the assignment to an issue. The article should not be archived until the issue to which it has been assigned is published.

With this in mind, it would also be convenient to develop a new filter in the submission menu that filters the active contributions according to their assigned issues. This could look like this:

I would be interested to know what other journals think about such a feature.
Do you consider this an improvement as well?

Kind regards,
Michael

Hello @adm_sub,

I’ve flagged your post in the “Feature Requests” category, but you may also wish to post an issue here: https://github.com/pkp/pkp-lib/issues, as a feature request, where our developers will be able to correspond with you on this and whether or not it would be feasible to add such a feature in future versions of OJS.

Best regards,

Roger
Public Knowledge Project staff

Hi @adm_sub,

a new filter in the submission menu that filters the active contributions according to their assigned issues

This has been done and will be available from v3.3.

submissions can only be scheduled for publication and assigned to a future issue after all production phases have been run through

It should be possible to assign a submission to an unpublished issue without scheduling it for publication. From the submission’s workflow go to Publication > Issue and click the “Assign to Issue” button. Assign it to a future issue. The next panel asks if you want to schedule it for publication. Click the “X” at the top to not schedule it for publication.

You’ll then have a submission assigned to an issue but not yet scheduled, so it will appear under active submissions.

Beware that submissions assigned to an issue but not yet scheduled for publication will not be published when an issue is published.

1 Like

Dear @rcgillis and @NateWr,

thank you for your quick answers.

This has been done and will be available from v3.3.

This is great news! I am looking forward to OJS Version 3.3, then.

Concerning my other question, assigning a submission to an unpublished issue without scheduling it for publication. I have tried the solution you suggested, but unfortunately, it did not work.

I’ve clicked the “Assign to Issue” button (in Publication > Issue), selected the issue and hit “Save”:

I closed the second panel by clicking the “X”:

Afterwards the submission was still not assigned to an issue:

But even if the proposed workaround would work, I would still argue that submissions should be able to be assigned to an issue during the production process without archiving them.

Kind regards

Hi @adm_sub,

You’re right, when assigned to an issue but not scheduled for publication, the issue field does not indicate this. Under-the-hood, the submission is actually assigned to the issue. You can see this by clicking on the Assign to Issue button again. The previously selected issue should be selected already. And when the issue filter comes in 3.3, that submission will be included when searching for submissions in the issue.

But we do need to better indicate this status in the field. We emphasized the need to schedule it for publication after editors were routinely assigning submissions to issues without scheduling them for publication. Looks like we forgot to highlight the other use case.

I’ve filed an issue to address this by more clearly designating each of the different states: https://github.com/pkp/pkp-lib/issues/6391. You can comment on my suggested wording here or there, and follow the issue for updates.