As a content editor I want to be able to move content (for example a page) in the CMS tree. When I do this at present a new version is created but this is merged with the previous update for that content. I want a new version to be created and the old version to be retained in order that the true date/time and editor of any changes is visible from the version history.
For example:
Editor A creates and publishes a page on 1 Sept 2024
Editor B updates and publishes the same page on 15 Oct 2024
Result (as expected) - Version history shows the 2 versions:
1 Sept 2024 - Previously published by Editor A
15 Oct 2024 - Published by Editor B
Editor C moves the page on 2 Jan 2025 in the content tree (which will update/save the page metadata as the sort ID will change)
Current result - Version history only shows 2 versions, losing the version from October:
1 Sept 2024 - Previously published by Editor A
2 Jan 2025 - Published by Editor C
Comparing versions it now looks like Editor C has made all the changes on 2 Jan 2025 which were in fact made by Editor B on 15 Oct 2024. The lack of traceability is a significant issue for our customer.
Requested result - Version history should show 3 versions
1 Sept 2024 - Previously published by Editor A
15 Oct 2024 - Previously published by Editor B
2 Jan 2025 - Published by Editor C
Note for Optimizely - We raised this as a bug in ticket 1584615, you have had internal discussions based upon this.
I strongly support this enhancement request. The current version handling during tree moves presents a significant governance issue that needs to be addressed.
The inability to maintain accurate version history when moving content means we lose critical audit information about who made which changes and when. This isn't merely about housekeeping - it directly impacts our ability to maintain proper content governance and accountability. Any content team would need to waste considerable time investigating content changes because the version history incorrectly attributes all modifications to the person who simply moved the content.
The current behaviour effectively rewrites history by making it appear that the editor who moved the content was responsible for all previous modifications. This is particularly problematic when tracking specific changes for compliance purposes or when investigating content-related issues.
The proposed solution - maintaining discrete versions for content moves - is a sensible approach that would resolve these issues whilst maintaining the integrity of the content history. This would bring the version handling in line with what one would expect from an enterprise-grade CMS.
I'd urge the Optimizely team to prioritise this enhancement as it addresses a fundamental need for accurate content attribution and history tracking.