Concurrent edit by two users may overwrite Web Content draft

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 6.0.5 GA, 6.0.12 EE, 6.1.0 CE RC1, 6.2.0 CE M2
• Fix Version/s: 6.1.1 CE GA2, 6.1.20 EE GA2, 6.2.0 CE M2
• Component/s: Web Content > Web Content Administration
• Labels:
  • QA-R
• Environment: Tomcat 6.0.29 + MySQL 5. 6.0.x Revision: 77848. ; Tomcat 7.0.23 + MySQL 5. 6.1.x Revision: 94906.
• Branch Version/s:
  6.1.x
• Backported to Branch:
  Committed
• Epic/Theme:
  • WCM
• Fix Priority: 3
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/3987

In JournalArticleLocalServiceImpl.java, the updateArticle() method checks for concurrent edits by testing the JournalArticle version. ArticleVersionException is thrown if the currently saved version number is greater than the version being edited.

This logic will fail to detect concurrent edits if multiple drafts are saved since each draft retains the same version number.

Possible solutions would be to check the modified date instead of the version number, or add an additional revision field to the JournalArticle table. Since version is stored as a double, it is not possible to store sub-revisions within the version number (e.g. 1.2.5).

These steps show how to reproduce without ever publishing. This is due to LPS-14911 which causes problems saving drafts. Once that fix is applied, these steps could be used starting with published content not just new content.

To reproduce:
1. Add Web Content Display to a page. Click "Add Web Content"
2. Make some changes and click Save as Draft.
3. Leave the editor open in this window and start a new session in a different browser. Go to the same page. The Web Content Display will show "<Content Title> is not approved". Click that "... not approved" link to edit the draft.
4. The draft content that was created in the first browser is loaded. Make some more edits and save as draft.
5. Going back to the first window which is still open in the editor, make some more changes and save.
6. The edits that were made in the second browser have now been lost.

This is similar to LPS-15307 where the same logic is used to manage Wiki edits.