[MGNLFORM-120] Content need an update when version 1.3 is installed Created: 30/Dec/11  Updated: 30/Nov/12  Resolved: 14/Jan/12

Status: Closed
Project: Magnolia Form Module
Component/s: None
Affects Version/s: 1.3
Fix Version/s: 1.3.2, 1.4

Type: Bug Priority: Critical
Reporter: Samuel Schmitt Assignee: Ondrej Chytil
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
causality
duplicate
is duplicated by MGNLFORM-144 Update of forms module from 1.2.4 to ... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLFORM-118 Update info.magnolia.module.form.proc... Sub-task Closed  
MGNLFORM-119 Cleanup content that contains old pro... Sub-task 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   

The version 1.3 of Form udpates the Form dialog.
Properties like "contactMailBody" and "confirmMailBody" are removed and are replaced by confirmContentType[text||html].
But this update is never applied to the content.

So if an author created a confirmation email on Form 1.2.4 and then updates to Form 1.3, when he opens the dialog, he wont see anymore the confirmation email message.
Bound to "confirmMailBody" before, the dialog expects that this message comes from "confirmContentType[text||html]" now.

An update of the content is required in the version handler.
We could try to follow the logic described in MGNLFORM-119.

Fortunately, the "sendEmail" processor is still working. It checks for both values... but it's a bit confusing. See MGNLFORM-118.

NOTE FOR STK:
PUR is extending Form and is also impacted. Its dialog extend "Form dialog", so maybe the same logic of content update should be added to the version handler of STK.

NOTE FOR Mgnl 4.5:
The old properties are replaced during the migration process.



 Comments   
Comment by Ondrej Chytil [ 12/Jan/12 ]

Not so sure about that update script. I'll log new issue for port of update task once/if it passed the review.

Comment by Jan Haderka [ 13/Jan/12 ]

I believe that the update task would be more efficient if it used HierarchyManager.moveTo() method rather then recreating NodeData for each change.

Comment by Ondrej Chytil [ 14/Jan/12 ]

In the end decided to leave task as it is.

Comment by Rory Gibson [ 29/Nov/12 ]

The reported issue here is causing a problem for us after update to 1.3.2 whereby the original values which were logged under contentTypetext are not appearing. When we add these values back in form settings, they get stored under contactMailBody which works fine. But this means we will have to manually change all the forms (we have over 150) to get this working again. Can you suggest any workaround?

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