Discussion and reviewer attachments should not be SubmissionFiles

[NateWr]

Describe the problem you would like to solve
Each SubmissionFile is assigned to a file stage and this determines where the file appears and who can access it. For example, a submission file in the SUBMISSION_FILE_FINAL file stage appears in the Copyediting list of files and is only accessible to users assigned to the copyediting stage.

However, access to discussion and reviewer attachments must be granted based on discussion and review assignments rather than file stage. This makes the authorization logic more complicated, and poses problems for writing API endpoints with consistent requirements.

For example, the REST API endpoints for accessing a single submission file require a file stage to be passed. But if the file stage is SUBMISSION_FILE_QUERY or SUBMISSION_FILE_REVIEW_ATTACHMENT, additional query parameters are required. This is hard to document and leads to unexpected results in the API.

Galley files present a similar problem discussed in #6702.

Describe the solution you'd like
Discussion and reviewer attachments should be separated from the SubmissionFile system. These files should only be uploaded and stored in the files table, not the submission_files table. Access to the files would be based on existing access policies for query notes and review assignments. The REST API would provide read/write access to these files only through endpoints for reviewAssignments/{id}/files and discussions/{id}/note/{id}/files.

Pros:

• Discussion and review files can have a simpler upload process since no genreId or metadata needs to be set.
• Authorization policies for SubmissionFiles are simplified.
• It's easy to support alternative kinds of file attachments for review files and discussions, such as public reviews of preprints, or discussion attachments for things like Google Docs.

Cons:

• I can't think of any

Who is asking for this feature?
Developers