track volume and issue number

[kmccurley]

Under the current model for the CiC journal, we will publish one volume per year and four issues per year. Each issue has a separate HotCRP instance at present. If a paper is submitted to the HotCRP instance for an issue, it may slip to a later issue for several reasons:

1. the paper is requested to be resubmitted to a later issue in hotcrp. In this case the author needs to resubmit, so it will appear in both hotcrp issues but will only be in one as an accepted paper.
2. once a paper is accepted in a hotcrp instance, it may still slip to a later issue if the author misses a deadline for submitting their final version. This would happen within this server.

For these reasons, we will keep track in this server of the volume and issue number, and they are first assigned by the submission URL from hotcrp. They may be changed later if a paper misses a deadline for final versions. Each paper will be tracked by the paperid, which is globally unique. That ID might be cic2023_2_5 to indicate that it was paper #5 in issue 2 of volume 2023. The paper would initially be assigned a volume of 2023 and issue number of 2, but the issue number (and volume number) might be changed. In this case the volume and issue number assigned to the paper might no longer match the values present in the paperid, but that's ok since it will be tracked separately from the paperid.

The method of storage for volume and issue number is TBD, but I assume it would be a table in the database. As soon as a final version of a paper is submitted, we would need to make sure to start tracking the volume and issue. There might be a way to insert a volume and issue into the database separately from the submission, so that we can start tracking papers from HotCRP via the API of HotCRP. That will be fairly unstable because of the nature of HotCRP.

[kmccurley]

I have updated the code to now store a journal, volume, and issue. It may seem weird to allow various journals, but there is no reason to make the code specific to a single journal. The database tables are currently defined as SQLAlchemy ORM objects, which makes me uncomfortable and there is a separate issue #29 on this. Issues must be identified as part of a volume, and volumes must be identified as part of a journal. A paper is identified as part of an issue, but the issue can be changed to another since it's just a foreign key reference. When a paper enters the system, it is assumed to be associated with some issue that might change later.

A journal has an ISSN, DOI prefix, name (acronym like cic), and longname. A journal has multiple volumes that are specified as a string in order to accommodate weirdos like TCC that wanted two volumes in the same year. An issue is similarly identified by a string, which typically would be a number but could also be named as a special issue.

[kmccurley]

There is an API to the IACR version of hotcrp that looks like https://submit.iacr.org/crypto2023/iacr/api/papers.php?auth=abcdefghijklmn. The auth code is created as an HMAC using a shared key between submit.iacr.org and is currently only used by s3.iacr.org. If we use submit.iacr.org/cic2024_2 to track volume 2024, issue 2 then we could fetch the list of expected papers, but in my opinion it is a bad idea™ to create records for papers based on the information in hotcrp, because authors often change titles, abstracts, author names, order of authors, etc. There are also failure modes like withdrawal of a paper in hotcrp after it has been accepted (there has been at least one instance of this in the past). It would show up as accepted in hotcrp, but would never show up in the final version.

The real purpose of this is to do a sanity check to see if all papers in hotcrp eventually show up as final versions in latex-submit. The way it works in the current upload of final versions is that s3 makes an api call back to hotcrp to show that a final version was uploaded based on the paper ID, using a convention that constructs the paper ID in s3 from the shortname (e.g., crypto2023) and the paper ID within hotcrp. We can try to carry that forward to make sure that hotcrp keeps a record of what paper was uploaded in final version.

[kmccurley]

There is now a hierarchy documented in the README.md that has Journal => Volume => Issue => Paper. Journal, Volume, and Issue all have identifiers stored in hotcrp that are transferred when a paper is uploaded. I still need to update the status in HotCRP when a final version is completed in publish.iacr.org. Presumably once the compilation works and it is sent to the copy editor, there should be an api call back to hotcrp to set the final version flag there.

[kmccurley]

There are still issues with managing the matching of papers to an issue. The PaperStatus object has a reference to the Issue it belongs to, but this can now be null if a paper is Unassigned. This would be used if we want to publish an Issue but a paper currently in that issue is not ready to be published. We would "unassign" it from the Issue and publish the issue, leaving the paper unassigned. The only problem with this is that the PDF for the paper already has the issue baked into the compilation, so when a paper is reassigned to an issue, it needs to be recompiled. I've created a #54 subissue to track this.

When a paper is "unassigned" from an issue, there may not be an issue to assign it to at that time, because an issue is only created when the first paper from HotCRP for that issue is uploaded in candidate version. The identifiers for a volume and issue are first assigned when the HotCRP instance is created for it. When the first paper is uploaded, it will automatically create Volume and Issue objects at that time. Only then can a leftover paper be assigned to that Issue.

When the editor views an Issue in the server, the papers that are pending for the issue can be in various states:

1. they may exist only in HotCRP at that time because the author hasn't yet uploaded their candidate version to the server. When a paper is in this state, there is very little information to show the editor, but at least its existence will show up because the server uses an API to contact the HotCRP instance for the issue.
2. the paper may exist in the server, but it may be in an incomplete state, either because it didn't compile yet, or it wasn't finalized by the author, or it wasn't copy edited yet, or the author didn't respond to copy edit, or the author's response was never accepted by the copy editor.
3. Once the copy editor "finalizes" the paper, it shows up as being eligible to be published with the Issue it belongs to.