This issue involves concurrent editing of the same page in 2 tabs by 2 different users, without realtime, it concerns the merge feature added by XWIKI-175.
Steps to reproduce:
* open a page in edit mode with user A
** let's assume this page is at version 1.1 at this point
* open the same page in edit mode with user B
** force lock if the question is asked (knowing that locks "expire" in 30 minutes if not refreshed)
* make a change (add a paragraph) with user B
* save and view with user B
** at this point, one more version was added in the history of the page, the page is at version 2.1, with a new block added
* back on the session of user A, hit "Save and continue" with user A, without making any changes
** the save will say, as a result "Saved by merging changes"
** version 2.2 is created for the page
** if the history of the page is checked, there is no difference between versions 2.1 and 2.2
* with user A, still without making any changes, hit "Save and view"
** no conflict is notified to user A
** the message for this save is "Saved" (not save with merge)
** version 3.1 of the page is now created
*Expected result:*
* there is no difference between versions 2.2 and 3.1
** otherwise put, the content that user B added at step 3 above are still there
If the expected result above is not possible, then user A should at least be informed that something has been deleted upon their save.
*Actual result:*
* version 3.1 deletes the content added by user B in the page
Technically, this is happening because, upon the "Save and continue" done by user A on step 5 above, the save and continue will update the "previousVersion" metadata of the page to hold version 2.2 (the new merged version) but the content of the editor / edit form is not updated with the data from the merged version.
Then, on the next save _of the same content_, the conflict system will not detect any conflict (because previousVersion corresponds to the latest version on server) and will update the page with the content of the form, which still does not contain the changes of user B.
*Aggravating context contexts: *
* autosave every 5 minutes, when checked, is performing a "save and continue" and then saving again, thus risking to completely transparently overwrite concurrent changes
* locks expire after 30 minutes on the server, but I don't know of any mechanism to refresh a lock from the client if an edit form is still open and inactive
** following the office editing pattern (web or desktop), some users may have a tendency to keep a page open in edit mode for a very long time, with or without autosave enabled |
|
