Description of issue (feature request, discussion of implementation)
During the submission process authors have to agree to certain conditions for their submission to be accepted for consideration in the journal. Currently the information which checkboxes where active at the time when an author submits a manuscript is not stored in the OJS database.
As to our knowledge, neither editors nor authors have any documentation about which of the checkboxes have been selected at time of submission. Complications could arise in case a journal at a later time decides to change the terms and conditions (checkboxes) authors are required to agree to. In this case no means are available of proofing which checkboxes had been selected (which terms were agreed to) at the time of submission.
The state of the submission checkboxes at time of submission should be documented for both the editorial side and the author at the time of submission.
This could be achieved in different ways:
Including the state of the checkboxes in the submission acknowledgement mail sent to the author and to the editor.
Different ways of implementing this feature can be envisaged:
Implementation in the pkp-lib or ojs core classes for mail template handling
Implementation as a plugin
Storing checkbox state in the “submission_settings” table and logging state at time of submission
For the implementation as a plugin a hook for dynamic alteration of the “Submission Acknowledgement” mail template would be required. Screening the code of the current OJS 3.x releases we didn’t find any hooks that could suit this purpose.
Questions:
Which of the above mentioned ways of implementation would be the more suitable one from the viewpoint of PKP? Or can you suggest alternative approaches?
For the implementation as a plugin, does a hook exist to attach to for adding the information to the mail template (submission acknowledgement) ?
If no hook exists, can a hook be provided for this purpose?
We would be happy to contribute to the implementation of this feature or develop a plugin ourselves.
Rather than doing this as a plugin, I’d recommend submitting the change directly to OJS/pkp-lib.
I’d recommend storing a copy of the journal’s submission checklist in the submission_settings as you propose.
I suggest checking the checklist contents stored in the submission against the checklist contents in journal settings when the user confirms the final submission step. That way if the checklist has changed in the meantime, they can be asked to review it. If they do match, the submission is complete and you can use the existing date_submitted column as the date of agreement.
Do you have something in mind for notifying the editor during the workflow process if the checklist that the author agreed to is no longer the current checklist in the journal settings?
Thanks,
Alec Smecher
Public Knowledge Project Team
That sounds great and submission_settings would work well. A fourth option would be to add an entry to the submission’s activity log. In addition to having the terms that were agreed to, you’d also get the date of agreement (which may differ from the date of submission).
I meanwhile have a prototype of the feature running on one of our OJS 3.1.2 test journals. I intent to port it to OJS 3.2 (3.3) and OMP once we are clear about all the features.
What I implemented so far:
In step 1 of the submission workflow the submission checkboxes, copyright notice and privacy statement are stored in submission_settings
In step 4 of the submission workflow the versions stored in submission_settings are compared to the versions in journal_settings. In case they differ the button “Finish Submission” is disabled, a list of the items that differ is shown together with a note to go back to step 1 to revise the terms and conditions.
If they didn’t change the submission can be finished as usual.
Only with clicking the button “Finish Submission” individual events for each item are logged in the editorial history.
I edited the SUBMISSION_ACK mail template (OJS level) to include all three items plus an additional statement in case the submission was performed with “Login As” (this is also logged in the editorial history).
I updated the English and German locales and SUBMISSION_ACK mail templates.
Open questions:
As it is implemented now every submission will store a full copy of each of the above items in submission_settings and the event log. To me this seems like a lot of redundancy and wasting of storage space. However, to improve this we would need something like a versioning system which would be more elaborate to implement.
The order of events in the editorial history doesn’t seem to comply to the order in which the events are logged in the code. Is this normal behavior?
How do we handle locales for other languages?
Did I miss anything?
The code (branch submission-checkboxes) can be found here:
I could also create an account for you on our test journal if you want to try it out.
That sounds great. From a usability perspective, I’m not sure about the re-confirmation in step 4. For most of our journals, the submission checklist is not a formal agreement but more of a pre-check: has the documented been formatted correctly, etc. Asking them to go back and re-check these things at the final stage, especially in cases where there is no formal consent being acquired or something, feels odd.
I agree that we should document the selected items. But I feel that we should document their action at step 1 and leave it there. It will be rare for there to be a dispute over what was agreed to, and the record will be there to adjudicate in such cases. But asking for reconfirmation of something that may not have substantially changed feels like we are in different territory.
To handle a more formal consent or confirmation process, we really need to do this at the end of the submission, probably during a final preview or confirmation step. There is a final “are you sure” step in the submission. Perhaps any formal consent statements need to be collected there?
Indeed, from our experience journals (at least here in Germany) do use the checkbox feature for more formal agreements. That is the reason why we started this project in the first place.
We completely agree that formal agreements should be collected at the end of the submission process. I see two options from this point:
Quick and easy: I leave the hint that checkboxes have changed but enable the “Finish submission” button again to make it optional to go back.
I move the checkboxes to step 4. Looking at the form this would leave “Comments for the Editor” and “Submit As” in step 1. This would be a significant change of the workflow which I wouldn’t do without your, i.e. PKPs, general consent. Probably there was a reason to have them in step one that I miss?
Hmm, this is a tough one. I think for most of our journals, it is a pre-submit checklist and needs to go into Step 1. For your use case, it is clearly a confirmation checklist and needs to go into the final Step. I don’t think we’re going to find a happy medium here.
We plan to overhaul the submission wizard in 3.4, in order to make it easier to customize the submission process. But that is not going to be available for a while yet, and I suspect you’ll need to have a working solution before then.
I can see two paths forward here:
We can have a new checklist, submissionConfirmation, that is added to Step 4 and which is saved to the submission’s history for later. That would be a worthy addition to the core application and we could migrate it properly when we refactor the submission process for 3.4. The downside is that you’ll need to build a UI control for creating/editing this checklist, which will be a fair amount of work.
You could implement what you need as a plugin for now, and then work to integrate it into core after the submission process is refactored for 3.4. At that time, I think it will be easier to implement a confirmation checklist.