[MAGNOLIA-5789] Restoring deleted nodes does not update mgnl:lastModified Created: 27/May/14  Updated: 04/Jun/14  Resolved: 04/Jun/14

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 5.2.6, 5.3

Type: Bug Priority: Major
Reporter: Mikaël Geljić Assignee: Daniel Lipp
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
caused by MAGNOLIA-5776 MgnlPropertySetting wrapper fails aft... Closed
supersession
supersedes MGNLUI-2946 Make sure restored nodes have proper ... 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 restoring a deleted page, old mgnl:lastModified date is also restored and consequently activation status is back to green.

Expected: mgnl:lastModified date should be updated to 'now', and status icon should be yellow.

This is filed in main because it was identified as a side-effect of MAGNOLIA-5776.



 Comments   
Comment by Daniel Lipp [ 28/May/14 ]

At runtime we have the following hierarchy of wrappers:

MgnlAuditLoggingContentDecoratorNodeWrapper
-> MgnlVersioningNodeWrapper
-> MgnlPropertySettingNodeWrapper

  • When restore is called on the Auditing one - it has no own impl of restore so the one from its parent DelegateNodeWrapper is called. This one simply forwards to restore on the wrapped node
  • Now the Versioning has a proper implementation of restore and will execute it - but it doesn't forward to any potentially wrapped node (in our case MgnlPropertySettingNodeWrapper)

This can be easily reproduced by e.g. running BaseVersionManagerTest#testCreateAndRestoreVersion

Comment by Daniel Lipp [ 02/Jun/14 ]

There seems to be something fishy - reopening until that's clarified

Comment by Jan Haderka [ 04/Jun/14 ]

I would maybe just add a note in BVM that this is necessary because restore is done via clone op that preserves mod date otherwise.

Generated at Mon Feb 12 04:08:24 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.