-
Type: Improvement
-
Status: Resolved
-
Priority: Critical
-
Resolution: Fixed
-
Affects Version/s: NoFixVersionApplicable
-
Fix Version/s: 5.3.1
-
Component/s: Direct Edit
-
Epic Link:
-
Tags:
-
Sprint:nxplatform #40, nxplatform #44, nxplatform #45, nxplatform #46, nxplatform #47, nxplatform #48, nxdrive #1, nxdrive #2, nxdrive #3, nxdrive #4, nxdrive #5, nxdrive #21, nxdrive #22, nxdrive #23, nxdrive next #24, nxdrive #25, nxdrive #26, nxdrive #27, nxdrive #28, nxdrive #29
-
Story Points:8
Current Flow
When Direct Editing a document, the current HTTP flow is:
- Fetch the document with its eventual lock and the permissions enricher.
- Download the associated blob.
- Lock the document (this is not consistent as it relies on the software that is editing the local file).
- Upload changes.
- Unlock the document.
This flow should stay the same when the advanced feature "Document auto-locking for Direct Edit" is disabled.
Better Flow
Given that the Document.Lock operation locks and returns the document, we could imagine another flow:
- Lock the document.
- Download the associated blob.
- Upload changes.
- Unlock the document.
Benefits
- We are saving 1 HTTP call (not really important here though).
- The lock is no more dependent of the software used to open the local file.
- Direct Edit would be atomic, e.g.: when one edits a document, it is locked early and nobody can apply changes to that same document.
Drawbacks
- The unlock part may be done after a Drive restart when the software used to open the file is using a process that Drive does not yet support. But that is to be mitigated: currently, a document can be edited without being locked because of the same cause. So either we have doc edition without locks and all possible problems, either we miss an unlock until Drive is restarted. The later could be improved, I guess.
- is duplicated by
-
NXDRIVE-1887 Display a message on forbidden Direct Edit lock action
- Resolved
- is related to
-
NXDRIVE-2128 Allow only one Direct Edition per document
- Reopened