SJRK-289: Add auto-save or caching feature for story authoring

Description

Add the ability to auto-save or cache story content on the user's local machine in order to mitigate server issues or losses due to accidental refreshing or otherwise.

Update
Given limitations on storing large files locally (as mentioned in Cindy Li's comment below), the new approach will be to auto-save the story and any associated files on the server.

Comments

• Cindy Li commented 2020-04-20T12:39:48.668-0400

  According to [the IRC discussion](http://irc-logs.fluidproject.org/%23fluid-design/%23fluid-design.2020-04-17.log), starting 2020-04-17T16:32:38, there are difficulties saving uploaded files in image, audio and video blocks. So the first implementation is to auto save all text contents including all in text blocks, block headings and descriptions and alt texts for audio, video and image blocks. but all uploaded files in audio, video, image blocks will be lost.

  [The pull request](https://github.com/fluid-project/sjrk-story-telling/pull/71) for the first implementation has been merged into the master branch at [this commit](https://github.com/fluid-project/sjrk-story-telling/commit/0a1d74d4bd4033d41869f2199508cc04c04afb01) and into the stories-aihec-production branch at [this commit](https://github.com/fluid-project/sjrk-story-telling/commit/b7a74dea9f1bd85cd77e4b5939f22ed1ed673bab).

• Gregor Moss commented 2020-04-22T13:49:56.088-0400

  I will be implementing the following steps in order to add server-side autosave:

  1. :check_mark: Planning the work and make this list (I'm so meta, even this acronym)
  2. :check_mark: Updating the version number of the project to 1.0.0
  3. :check_mark: Updating UUID call to use v4 instead of v1
  4. :check_mark: Adding new values to the story model
     • Published
     • Timestamp for initial creation
     • Timestamp for last modification
     • Timestamp for publishing
     • Salted hash of a CSPRNG or similar to make sure nobody else can finish the author's story
  5. :check_mark: Adding "published" restriction to storiesById view on the DB
     • if (doc.value.published) { ... }
  6. :check_mark: Updating View request handler to prevent viewing unpublished stories
     • sjrk.storyTelling.server.handleGetStory()
  7. :check_mark: Adding new request handler to post a story without any files
     • It should call sjrk.storyTelling.server.saveStoryToDatabase()
  8. :check_mark: Adding functions, listeners, etc. to call this new request
  9. :warning: Adding code to check the timestamps, or to check differences in the story
     1. This step is not currently necessary; the story update process will be one-way and conflicts will be resolved with the client's version always being correct.
  10. :check_mark: Adding new request handler to post a single media file only
  11. :check_mark: Adding code client-side to call this request
  12. :check_mark: Modifying the uploader component to work nicely with this request
  13. :check_mark: Modifying sjrk.storyTelling.base.page.storyEdit.submitStory() to switch flag
  14. :check_mark: Creating a progress indicator for file uploading in block editor
  15. :info Ensuring tests have been added for all new functions, grades, etc.
  16. Updating documentation to reflect code changes

• Gregor Moss commented 2020-05-19T14:24:50.322-0400

  There are a few tasks which were not accounted for in the initial estimate, or which have arisen out of further discussions since then:

  1. :check_mark: Removing a block's old file from server on new file selection
     1. Getting the newly-added removePreviousStoryFile middleware working
  2. :check_mark: Getting progress indicator working for audio and video blocks
  3. :check_mark: Removing fileDetails from code, if it is indeed unused
  4. :check_mark: Getting timestampLastModified working
     1. No change debouncing or throttling necessary, as gpii.binder only operates DOM-to-model updates on text defocus
     2. File a new Jira for saving on exit/close, if possible SJRK-357
  5. Restricting publishing while upload is in progress
  6. Restricting preview while upload is in progress
  7. Adding tests for all new functions and invokers
  8. Updating docs to reflect changes
  9. Addressing any PR feedback as it arises
  10. Deploying to staging site
  11. Testing via the Manual Testing Grid
  12. Address any blockers from the testing session
  13. Deploying to production versions of the site
  14. Testing production versions to ensure no regressions

  These tasks need to be (re)estimated (by me) and incorporated into an overall estimate of remaining work.

  Legend:

  :check_mark:: done

  :info: in progress

  :warning:: note

• Gregor Moss commented 2020-07-14T01:36:56.495-0400

  Design questions from the Priorities Spreadsheet:

  Question	Status	Dana's Answer
  When should auto-saving the story occur?	Implemented	if we can do it on every change then let's do it
  When should an auto-saved story load?	Implemented	In any case where user leaves the tool/browser
  When should an auto-saved story be cleared?	Implemented	I guess once it's published - this is not user facing in any way, right? so whatever makes sense technically I think
  Should an auto-saved story include empty blocks?	Implemented	yes
  Should media (audio, image, video) be stored with auto-saved stories?	Implemented	yes
  Do we want stories-in-progress to be accessible publicly? I.e. unlisted	Implemented	no
  Should we disable publishing while files are uploading?		Yes
  Should we disable viewing the overall story preview while files are uploading?		Yes
  If we decide to save text content locally, how often should the server be updated?	Not implemented (not necessary?)	every minute
  Security considerations for story in progress	Implemented	story ID is the security key, for the time being

  For more context and discussion notes, please refer to the spreadsheet proper.

• Gregor Moss commented 2020-09-15T00:26:32.307-0400

  I've attempted to determine (without going too deep into the weeds) what the most common/likely errors would be when uploading a file to the server, once this work is completed.

  These error messages would be shown on a given (individual) block and pertain only to that block's file, and will not be shown in the publish story error area.

  Each of these messages will be preceded by "Uploading failed:" before providing more details:

  • "Connection to the server timed out after X seconds"
    • When the response from the server takes more than X seconds, regardless of the reason
    • X is currently set (somewhat arbitrarily) to 5 minutes (300,000 ms). This value should be parameterized and perhaps moved to the server configuration file (in a different Jira, probably)
  • "Error retrieving story with ID {STORY ID HERE}"
    • This is when the story ID in localStorage points to a story that doesn't exist in the database. Not likely in regular usage unless a stale story is deleted, a point that can be revisited as part of SJRK-345.
  • "Error retrieving story with ID null"
    • Same as above, but when local story save has no ID provided. Will occur if a new story is created while the database is down but the web server is not
  • Server out of storage space - exact error text has not been observed at this point, only a hypothetical case and is not actually checked-for in code
  • "Unable to connect to the server"
    • Transfer connection interrupted partway or could not be established in the first place
    • To reproduce: after loading the editor and adding a media block, turn off the web server and then try to upload any file
  • "An unspecified server error occurred"
    • Displayed when no other error information is available