🤔 I have two failures in the tests, but I can't pin-point them to something related to these changes:

Output of ...manage test... (edited for clarity)

FAIL: test_orcid_registration (src.core.tests.test_app.CoreTests.test_orcid_registration)
...
Couldn't find '<input type="hidden" name="orcid" value="0000-0000-0000-0000" id="id_orcid">' in response

FAIL: test_reviewer_decision_form_no_decision (src.review.tests.ReviewTests.test_reviewer_decision_form_no_decision)
...
'<option value="" selected>...' not found in '<label for="id_decision">Recommendation:...

----------------------------------------------------------------------
Ran 639 tests in 118.368s
FAILED (failures=2)

It's been a while since I've run Janeway's tests, I hope I'm not doing something wrong 🙂

I'm setting this MR as ready, but please feel free to set it back to "draft".

oops pieces missing...

Hi @gamboz, can you say a bit more about why you'd like to have the editor control DOI registration manually? In the past we have found editors are helped most when Janeway handles this for them, but we want to understand the user story you have in mind to make sure. Thanks!

say a bit more about why you'd like to have the editor control DOI registration manually...

Yes, sure.

It's actually more about not registering at acceptance; we plan to have the system register the DOI automatically at publication (in the near future).

Depending on the journal, we can have these situations:

• we don't want to let readers access accepted but non-published
  papers, so we can't provide a web page to be linked to the DOI at
  acceptance
• the form of the DOI depends the article's primary issue at
  publication and how many other articles of the same type (section)
  have been published in that issue (this is for "historical"
  reasons[*] and will probably review this decision); we cannot know
  this number at acceptance because the publication order depends also
  on how fast the production process goes for every paper
• we have had (rarely) papers withdrawn after acceptance

Consider also that most of our papers came from pre-print archives and
our typesetters are relatively fast (1~2weeks from acceptance to
publication), so the added bonus of registering the DOI at acceptance
is minimal for us.

[*] We had persistent identifiers before DOIs and used that kind of
logic to build these PIDs, then we brought the same logic into the
format of the DOI, but we see no reason to continue this solution ATM 🙂

Thanks @gamboz, that helps explain the context. Small follow-up question: For most Janeway journals, registering the DOI at acceptance ensures that it can be used in typesetting, when inserting article metadata into publication-ready files. In your workflow, how can you be sure in typesetting what the DOI will be? Do you have a process for reserving the DOIs before typesetting that does not involve creating it in Janeway?

As for including the issue in the DOI, yes I would encourage you to move away from that.

... registering the DOI at acceptance ensures that it can be used in typesetting, when inserting article metadata into publication-ready files. In your workflow, how can you be sure in typesetting what the DOI will be? Do you have a process for reserving the DOIs before typesetting that does not involve creating it in Janeway?

Our process is roughly this:

• we typeset in latex and add "placeholders" for DOI and publication date in the typesetted source files
• during production, galleys show the placeholders
• at publication (here), the system computes the DOI and sets it and the publication date in place of the placeholders
• galleys are re-generated

OK, I'll take this back to the team for discussion.

... registering the DOI at acceptance ensures that it can be used in typesetting, when inserting article metadata into publication-ready files. In your workflow, how can you be sure in typesetting what the DOI will be? Do you have a process for reserving the DOIs before typesetting that does not involve creating it in Janeway?

Our process is roughly this:

* we typeset in latex and add "placeholders" for DOI and publication date in the typesetted source files

* during production, galleys show the placeholders

* at publication ([here](https://github.com/sissamedialab/wjs-profile-project/blob/c52dfa96571ea2190e9ec27e282bf9ae9b6d4963/wjs/plugins/wjs_review/logic__production.py#L1394)), the system computes the DOI and sets it and the publication date in place of the placeholders

* galleys are re-generated

I'd love a demo of this process, we have other jourals using TEX!