Add a check for a stale edit lock on start up

[djplaner]

For various reasons there may be a stale edit lock hanging around.

• [x] Decide between adding it to onMount or as part of turn edit lock on
• [x] Modify "saving" to do a check for staleEditLock - tweaked - sort of already there
• [x] Test with another computer that is in save mode - windows box
• [x] Tidy up the code - comments and debugging
• [x] Document? - at very least mention edit lock in docs

Current design

• Stale edit locks are detected as part of the turnEditOn process. If any detected they will be overwritten.
• Holder of stale edit lock will not be able to save - the next time they try to save the interface will be turned off

[djplaner]

Design exploration

Initial thought is to do this in the editOnController as part of turning the edit lock on.

Most of it is there at the moment. The challenge is the long chain of disconnected functions. In particular, the chain associated with turnEditOff. Most of this is working, having deleted the file. But we get to finalCheckForEditOnOff and it's coded to call finishCallBack - when it should not do that

Should it

• Call another callback what?

Mabye have to set a private member to distinguish.

Documenting

Turn edit on

• canvasSetUp::getPageName - async canvas API
• this.checkEditingDetails - call back from getPageName
  • updateEditingDetails - figure out what to do with the editing details
    • check for stale edit lock
      • try to turn it off & then we have to try and complete the original turn edit on
    • otherwise set editing on status
      Depending on the values from the found edit page, set the editing status
  • if no-one editing - create the editing page should have a check here for when returning from stale edit lock???
    • creatEditingPage
      • create the page for the current user
      • checkCreation - similar to checkEditingDetails
  • else finishCallBack

Current plan

IF we simply set editon status to NO_ONE_EDITING the normal turn edit on process will

[djplaner]

Checking self for stale edit lock

When I am the user with a stale edit lock. Need to detect and tell me about it and modify the interface ASAP.

WHen should/could it be done?

• save interval
• any attempt to make change. -- reactive on $configStore[needToSaveCollections] - when changed

What might it look like

• Is it just based on the time I obtained the edit lock - nothing to do with the edit lock page?

What should it do

• Modify the interface to show that edit is off
• generate a toast warning

Exploring how

• toggleEditingOn - set the timeLockObtained value
• toggleEditingOff - reset the timeLockObtained value
• setSaveInterval
  • creates what is done when checking
  • add in check for stale lock - similar to Canvas refresh date check but using new property timeLockObtained

[djplaner]

Requirements

Has the stale lock

• Should only happen when compute is suspended - if still open the time release should work
• their editing lock has gone way (probably, but not necessarily)
• need to
  • detect that the lock is stale
  • prevent them saving any changes
  • warn them about the isssue

Found the stale lock of another

• editing lock is owned by someone else - it's stale
• need to update the lock to their own and away they go

[djplaner]

Detecting stale lock for "has stale lock"

• One suggestion is onMount but that doesn't get called when a suspended computer comes on
• need to detect stale lock on events

Only delete lock file if you own

• Appears that turnEditOff doesn't care if you don't own the current edit file NO

• reload the page object

• if it's our details - remove it

• if it's not our details - fail - but allow the browser to turn off the editing option

turnEditOff

• getPageName - bind to checkEditOffDetails
• checkEditOffDetails
  • our details.- call deleteData
  • not our details -ignore
  • call finishCallBack

Implemented this

[djplaner]

Mapping process again - editingOnController

turnEditOn

• getPageName -> async
• checkEditingDetails
  • updateEditingDetails
  • no_one_editing -> createEditingOnPage()
  • else finishCallBack -- and error

createEditingOnPage -> async postData

• checkCreation
  • updateEditingDetails
  • you_editing -> getPageName -> finalCheckForEditOnOff
  • else finishCallBack and error

finalCheckForeditOnOff

• updateEditingDetails
• finishCallBack and likely success

turnEditOff

• getPageName editing on -> async
  • canWeTurnEditOff
    • updateEditingDetails
    • you_editing -> wf_delete_dat -> checkDeletion(date)
    • else finishCallBack - errror

checkDeletion

• getPageName -> async
  • finalCheckForEditOnOff
    • updateEditingDetails
    • finishCallback

[djplaner]

Mapping what happens with stale

The pure turn on and off is working fine. It is the way in which stale lock is detected (by the different actors) and what happens where the problem occurs

updateEditingDetails is calling staleEditLock

This check for staleEditLock is causing some disruption. -- this check should be done outside???

Looking to move the stale lock check out of updateEditingDetails

Question is where does this check need to be done

• turnEditOn
  • if it's YOU_EDITING status - we probably need to update the page - does this happen?
  • if it's someone else editing - we need to remove the file before starting the process again
• turnEditOff
  • if it's YOU_EDITING status - we can just delete
  • if it's ANYONE else - just delete -- if all we're doing is delete

EditingOnController seems to be working CanvasCollections is next

The nuts and bolts of turnEditOn/Off is happening, but the higher level - esp. for holder of stale lock - is not happening.

• The proper messaging
• The proper working

[djplaner]

Test cases

• Does the holder of stale know what's happening
• Can the holder of a stale lock make saves to the configuration file --

saving to the configuration file

Where is the saving done

• setSaveInterval - every TIME_BETWEEN_SAVES try and save - via startSaveCollections
• setUpImport - when doing proceed - via collectionDetails
• initialiseCollections - via collectionDetails
  • when is this called, is this the right way? - probably a race condition there
• checkBeforeUnload - via startSaveCollections
• toggleEditingOn - via collectionsDetails
• click on save button - via startSaveCollections

startSaveCollections - calls isStaleEditLock

• if there's a timeLockObtained date and eidtingOn has a value (i.e. we're editing)
• check the time between timLockObtained and now doesn't indicate stale
• if so, use turneEditOff

It is working here - not being able to save and getting repeated errors - but that's because we're not correctly remove it

Updating the user interface

Working - but the turningEditOff is removing the edit lock when it is owned by someone else...not what we want here