Build a way to "lock" a document while a user is editing

[jmikrut]

If a user is editing a document, it should set a flag on the document as "being edited by". Then if another user visits the document, it should show a popup window that alerts them to the fact that the document is being edited by that user and prevent further editing. Maybe give an opportunity to "take over" the document.

EDIT: Document locking was released in 3.0

[hades200082]

Possibly a better solution here would be to allow collaborative editing.

Kontent.ai do this by locking only the field being edited, not the whole document. Other editors can see the field "disabled" while one is editing it, and can click a "refresh" button to update their view with what the one editor has changed.

[chladog]

Alternative would be collaborative style of editing like GoogleDocs. Editors would be able to see their cursors and changes in real-time working on RC version and when ready they would publish it. A lot of effort, but I believe it would make it the first CMS impementing this ever, great USP.
In either case this is great case for sockets.

IMHO this topic should be of a great priority. In my project we already had few upsetting times when two people were working on a same page and overwrote their changes, some tears went out as well :,-(

[hades200082]

There's a reason no other CMS implements this. The diffing algorithms used in the communication that syncs the multiple participants are incredibly complex and error prone.

I remember back in the early 2000's that Google released a library called DiffMatchPatch that did the diffing part and was very good... but it's not been updated in ages.

On top of the diffing though, there's also the need for automatic conflict resolution. Even in OneDrive/SharePoint this sort of feature often results in duplicate documents being created as "conflicted versions".

Finally, just because it's a technically cool feature doesn't mean it's the best UX.

Overall, it might be better to avoid the complexity and conflict issues if there's an easier way to do it that also offers a better UX.

[chladog]

Great insight. It's definitely a complex solution with a lot of technical challenges.
I believe there are more ways how to handle sync of the changes. For example Quilljs Delta format handles this nicely as only partial changes at the cursor location are being sent back and forth, basically you can just make a ledger of changes since the last snapshot.
I like your proposal as well though IMHO real time updates on the locked field without a need of hitting refresh btn would be better UX. So basically user focuses field -> locked for other users, then on blur the changes are pushed to other editors and the field is unlocked.
Still I believe such changes should happen on the draft version not the published one until user press Publish btn.

[hades200082]

Still I believe such changes should happen on the draft version not the published one until user press Publish btn

This is a good point - any implementation of this feature will likely require version history and drafts.

[wala0003]

Collaborative editing is worth the technical challenge for a next gen cms

[cbratschi]

Directus is working on such a feature using their new WebSocket API. Using WebSockets it should be easy to lock a certain document similar to the way WordPress does.

https://codex.wordpress.org/Post_Locking

[MarkAtOmniux]

This might not be great for people who use Lamda or Cloud Run to host their Payload instances. We would need to increase the number of concurrent connections and that will drive up the price. An alternative could be simply locking the field in the DB (or a redis cache?) and then unlocking it once the field or window have lost focus. Any other user currently looking at the same document would poll every 3 or 5 seconds to see if the field is still in use in the DB. Or we could create a WebHook rather than a websocket, and that way we don't need to continuously poll.

[cbratschi]

Yes, a database lock field would be the simplest way. WebSockets can be used with Express but are difficult to handle in cluster mode because the listeners run in a single process and IPC would be required for synchronization.

I would recommend:

• API to acquire lock: either fails or client got the lock (returns lock time and user ID).
  • Parameters: force (for forced take over of lock)
  • Lock field in MongoDB (e.g. editLock) stores the timestamp the lock was acquired or last renewed and the user ID.
  • Lock is lost if not renewed for 15 seconds.
• API to renew lock (parameter: last lock time; current user is known)
  • Only renews if timestamp matches (otherwise someone else took over the lock)
  • Polled every 5 seconds for instance.
• API to get state of lock (timestamp, user).
• Frontend shows popup if locked by another user (go back, take over).
  • Polling needed to check for state changes and UI updates.

This should also be taken into account in mass edits. There might be problems with version conflicts but users should be aware if they perform multiple take overs data will be overwritten or lost.

[SalahAdDin]

@cbratschi does not work with either websockets or webhooks, right?

[cbratschi]

@SalahAdDin this would work really well with WebSockets because the lock is on the database level. If you use a memory lock it gets complicated with WebSockets in combination with Node.js clusters.

Not sure which WebHook use case you envision.

[jacobsfletch]

@isaackoz brings up great points in this thread: #3109 (comment) and again here: #3217 (comment) which is that we might want to think through how we might handle server events happening in the background, i.e. hooks from another collection that might have updated the document while the user is making edits. Not that this is technically similar to locked document editing, but the goals are the same, which is to prevent accidentally overriding valid changes. At least in the design phase it seems like we should be considering how to best handle this.

[vibhor-web-headout]

Hi Team,
Is there any ETA for this item?

[PP-Tom]

https://payloadcms.com/ the video on the homepage at the top shows collaborative editing. Is this current functionality?

[SalahAdDin]

I guess it is a premium feature.

[rburgst]

in #7970 it seems this was added. However, depending on the number of editors, optimistic locking would probably make more sense as it reduces the load on the database. Pessimistic locks (as it was implemented) is usually always a hassle and hard to get right, and if you get it right you will produce DB deadlocks.

[swenzel-arc]

I'd like to suggest another way to solve the underlying Problem.
It is more heavy/complex on the frontend but might solve a few of the synchronization, locking and background task related issues in the backend.
What if the system uses and honors the ETag Header?
When a user tries to update a document based on outdated information, the backend will answer with a "412 - Precondition Failed" response. The Frontend could then load the latest version and provide the user with a three-way-merge-like interface to resolve any conflicts and then save the document including all intermediate changes.