Overhaul In-progress Transfers

[danloveg]

The UX and backend code for in-progress transfers could use a refresh, and the urls for the in-progress transfers should be brought more in line with REST methodology.

Backend Changes

• SavedTransfer should be renamed to InProgressSubmission.
• InProgressSubmission needs a uuid field.
• The URL transfer/delete/<int:transfer_id>/ should be changed to inprogress/<uuid:uuid>/delete/.
• The inprogress/<uuid:uuid>/delete/ should delete without asking for confirmation before re-directing to the user's profile. A message should be shown that the in-progress transfer was deleted.
• A new view inprogress/<uuid:uuid>/delete/confirm/ should be added which returns the confirmation page.
• Clicking OK should trigger the /delete/ flow (see above).
• There should be no limit on the number of past transfers a user can have (i.e., remove MAX_SAVED_TRANSFER_COUNT).
• If it's feasible, a new view at inprogress/<uuid:uuid>/resume/ should be added that resumes the given transfer.
  • Currently, the transfer/ url is used with a GET parameter to resume.
• There should be a new view at transfer/save/ which creates a new InProgressSubmission with the form's state.

Frontend Changes

• The in-progress transfers should be paginated if they aren't already.
• The in-progress transfers table should look like this:

• The deletion confirmation page (inprogress/delete/uuid/confirm/) should look like this:

• The button on the transfer form should be changed to a link: