Refactor submission checklist feature to reusable custom checklist feature



Hi there,

I need to use the features of the submission checklist code (e.g. add elements, …) in my own code / customized parts of OJS.

To avoid recreating the wheel I want to refactor the existing code in such a way that it is reusable hence the name custom checklist. It would require almost similar operations as described in issue Refactor review forms feature to reusable custom forms feature. Also to avoid the need to merge constantly between possible submission checklist changes and my own custom checklist code i would like to provide a pull request to get the chances into the official repo. Is there a chance that the PR would be accepted?

What do you think?

So lonG


Hi @j1shin,

Am I right in thinking that you want to have a custom form that authors must fill out when submitting? So instead of just a checklist, they may also have input fields, select fields and other kinds of input?

If so, you’ll probably run into the same caveats that I described in this comment on the issue you linked. In short, I’m in favor of the idea but because we are doing some major refactoring of our form handling, now is a difficult time to merge in code, because much of what you will build off may change in the next year.

I’d encourage you to file an issue in our GitHub repo that provides more details about what you want to be able to change in the submission forms. That will help us design something that is more flexible when we get to it. And we can discuss ways in which you might build off of the new form system once it is released with 3.2. Depending on your timeline it might be possible to do your work on top of that.


Hi @NateWr,

no, i just want to reuse the checklist functionallity, to be specific, we have the requirement of “submission checklist per section”. So i need to be able to configure a submission checklist per section, not per journal as it is implemented currently. Simply speaking, what i would do is to

  • provide an extension point to specify the context (currently its simply the journal retrieved from the request)
  • using that extension point in submission step 1, grid handler and form
  • defaulting the context to the journal as it is implemented right now

Ok, i forgot about the currently ongoing form refactoring, hmm i guess i will fiddle something together and create a issue / PR afterwards to show you the changes as describing it with just words is a bit difficult.


Ah, I see. So the trickiest part will actually be in creating the UI to create new checklists for each section. You can see an example of how we extend the forms to add/edit a section to add new fields in the BrowseBySection plugin:

Once you have those, you’ll need to pull the checklists out during the submission process, and write a little JavaScript that displays the correct one depending on which section has been selected.