I'm trying to mitigate the problem of concurrent edits of contents.
In Umbraco, if two users Alice and Bob work together on a content, both save the content and Bob saves after Alice, Alice's modifications are overwritten and Bob has no evidence of the issue.
As a strategy I thought of blocking the second user's changes. If Bob saves for second receives an error "The content has a more up-to-date version…”.
He can still open the new version of the content and merge the changes he was making with those entered by the other user. How can I implement this strategy?
I thought of saving the version id when a user opens the editor for a content (SendingContentNotification). On saving (ContentSavingNotification) I'm going to check that the id is still the last one for the content. But where do I save the version id? There are no hidden properties in the content that can be used for this purpose.
I tried to store in an in-memory dictionary (user.id, content.id) -> content.versionId, updated when the content is opened (SendingContentNotification). In ContentSavingNotification I allow saving only if the version for (user.id, content.id) is equal to the versionId of the updated content. It works once, but after the first failed save SendingContentNotification is called, the content is reloaded (the user do not see the most updated version but the local one) and the dictionary updated, so the second save action works.
When a user Saves in a Uesr Session, it doesn't create a new version for each save, it just updates the last saved version. In V7 and below this was always specific to the User editing, So in the Bob and Alice scenario, if Bob saved after Alice, it would create a new version in the history, instead of overwriting Alices changes. So historically you could sort of work it out and retrieve previous work in progress and manually resolve the issue. However in V8 - I think accidentally, the 'per user' bit was dropped, so now when Bob saves it just updates the last saved version after the last publish.
So the no tech change workaround, is to have a user 'publish' their work when they are finished, and then rollback to the previous version if those changes shouldn't be live yet... crazy!
Anyway there have been quite a few packages released over the years to try and handle this scenario, the most recent of which for V8 ONLY is Cogworks Content Guard:
Whilst this is V8 ONLY a lot of the concepts (and probably the code too) still apply.
There is for example a concept in Umbraco called 'Relations' you can find the 'Relations' tree in the 'Settings' section. (introduction here: docs.umbraco.com/umbraco-cms/fundamentals/data/relations/)
Anyway this allows you to create a new Relation Type, eg ContentLocked
And then use this to temporarily store which User is currently editing a document.
If you looking ContentGuard source - you can see the logic behind this:
Then when an editor opens a document in Umbraco you can use the EditorModel SendingContentNotification to check to see if the page is locked by someone else by looking at the relations for the page.
And when saving you can check for relations and stop the new editor from saving, with a message (but be careful as this will break things like 'sorting' if someone has locked a page!)
And additionally Content Guard has a content app for the content item showing if it's currently locked and by whom and allowing it to be unlocked, or 'taken over' by another editor, if the in progress editor is on holidays.
When a page is published you could remove any locks.
Anyway hope that gives you a bit of an inspiration, if you had the time then bringing ContentGuard (as it's open source) up to scratch with V9 would be possibly the coolest approach!
This is v10 package available that doesn't stop multiple editors from editing content, but informs each of them when someone else is also editing the content:
Concurrent edit of contents
I'm trying to mitigate the problem of concurrent edits of contents. In Umbraco, if two users Alice and Bob work together on a content, both save the content and Bob saves after Alice, Alice's modifications are overwritten and Bob has no evidence of the issue.
As a strategy I thought of blocking the second user's changes. If Bob saves for second receives an error "The content has a more up-to-date version…”. He can still open the new version of the content and merge the changes he was making with those entered by the other user. How can I implement this strategy?
I thought of saving the version id when a user opens the editor for a content (
SendingContentNotification). On saving (ContentSavingNotification) I'm going to check that the id is still the last one for the content. But where do I save the version id? There are no hidden properties in the content that can be used for this purpose.I tried to store in an in-memory dictionary
(user.id, content.id) -> content.versionId, updated when the content is opened (SendingContentNotification). InContentSavingNotificationI allow saving only if the version for(user.id, content.id)is equal to theversionIdof the updated content. It works once, but after the first failed saveSendingContentNotificationis called, the content is reloaded (the user do not see the most updated version but the local one) and the dictionary updated, so the second save action works.I'm asking for some ideas/strategies.
Hi Michele
When a user Saves in a Uesr Session, it doesn't create a new version for each save, it just updates the last saved version. In V7 and below this was always specific to the User editing, So in the Bob and Alice scenario, if Bob saved after Alice, it would create a new version in the history, instead of overwriting Alices changes. So historically you could sort of work it out and retrieve previous work in progress and manually resolve the issue. However in V8 - I think accidentally, the 'per user' bit was dropped, so now when Bob saves it just updates the last saved version after the last publish.
So the no tech change workaround, is to have a user 'publish' their work when they are finished, and then rollback to the previous version if those changes shouldn't be live yet... crazy!
Anyway there have been quite a few packages released over the years to try and handle this scenario, the most recent of which for V8 ONLY is Cogworks Content Guard:
https://our.umbraco.com/packages/backoffice-extensions/content-guard/
Whilst this is V8 ONLY a lot of the concepts (and probably the code too) still apply.
There is for example a concept in Umbraco called 'Relations' you can find the 'Relations' tree in the 'Settings' section. (introduction here: docs.umbraco.com/umbraco-cms/fundamentals/data/relations/)
Anyway this allows you to create a new Relation Type, eg ContentLocked
And then use this to temporarily store which User is currently editing a document.
If you looking ContentGuard source - you can see the logic behind this:
github.com/thecogworks/Cogworks.ContentGuard/blob/master/src/Cogworks.ContentGuard.Core/Services/ContentGuardService.cs
Then when an editor opens a document in Umbraco you can use the EditorModel SendingContentNotification to check to see if the page is locked by someone else by looking at the relations for the page.
And when saving you can check for relations and stop the new editor from saving, with a message (but be careful as this will break things like 'sorting' if someone has locked a page!)
And additionally Content Guard has a content app for the content item showing if it's currently locked and by whom and allowing it to be unlocked, or 'taken over' by another editor, if the in progress editor is on holidays.
When a page is published you could remove any locks.
Anyway hope that gives you a bit of an inspiration, if you had the time then bringing ContentGuard (as it's open source) up to scratch with V9 would be possibly the coolest approach!
regards
Marc
This is v10 package available that doesn't stop multiple editors from editing content, but informs each of them when someone else is also editing the content:
https://marketplace.umbraco.com/package/arjo.umbracobackofficeeditorview
It's a fairly new package, but it could help your editors talk to each other to overcome the issue of concurrent editing.
Nik
is working on a reply...