[MAGNOLIA-3332] Delete versioned content on deletion of main content Created: 22/Oct/10  Updated: 28/Jul/11  Resolved: 22/Jul/11

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 4.3.7
Fix Version/s: 4.4.5

Type: Bug Priority: Critical
Reporter: Jan Haderka Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
relation
is related to MGNLTOOLS-46 Create command for clean out versions... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When content is deleted, it's versioned counterpart from mgnlVersion is not deleted so the versions of such content are not purged. Ideally we delete mgnlVersion copy of content together with the original or in the least we should run the cleanup job on the instance to purge such content periodically.



 Comments   
Comment by Danilo Ghirardelli [ 07/Jul/11 ]

Is this internal cleaning of nodes or this means that there will be no way to see deleted content even accessing to the parent node? One of the best feature of versioning should be to retrieve or see (accidentally) deleted nodes...

Comment by Jan Haderka [ 07/Jul/11 ]

Staged deletion of the content is already implemented and nothing is going to change on this.
This issue is about internal version history which was never ever removed thus occupying extra disk space forever.
Or do you think staged deletion is not enough and you would want to retain version history anyway even after content is gone for good? AFAIK the only way to reclaim such version history at the moment is to reimport previously exported base version of such content.

Comment by Danilo Ghirardelli [ 07/Jul/11 ]

Well... You know the average user... Confirm messages are never really read, and you understand that something is missing only when it's in public production... And unfortunately there is no separate "DELETE" permission that you can deny to the average user.
I was hoping that keeping the version after the content deletion would give a chance to get it back somehow, accessing the parent or whatever. It's not a feature that is always needed but may be useful in some projects.
Obviously if there isn't and there will never be a way to access that data, it's good to delete it, but if there is a chance to get it, even programmatically, I'd like to choose if keeping this data or not (just like the choice on how may versions keep).

Comment by Jan Haderka [ 07/Jul/11 ]

By that logic you should never ever delete or throw away anything
Since we implemented staged deletion, the delete itself is done via workflow. If you want to, you can easily add step there that will actually export content to the file system so you have such fail safe process to get it back. Similarly you can retrieve content again from the backup of your production environment that you are surely making. And last but not least - staged deletion means that you need to delete in 2 steps - first you mark content as deleted and then you activate such deletion. This usually involves more then one person and rapidly lowers the chance of accidental deletion. Only once deletion is activated, the versions are purged. This whole process is described in the release notes of one of the recent versions.

Comment by Jan Haderka [ 22/Jul/11 ]

Done for both 4.4 branch and trunk. The test for direct deletion on JCR API in trunk will fail until SCRUM-310 can be fixed.

Generated at Mon Feb 12 03:45:28 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.