[MGNLMIGRATION-14] The content created by a dialog/control of type "mutliselect" must not be updated. The primary type must stay "mgnl:contentNode". Created: 18/Nov/11  Updated: 23/Apr/13  Resolved: 29/Mar/13

Status: Closed
Project: Migration 4.4 to 4.5 (closed)
Component/s: None
Affects Version/s: None
Fix Version/s: 1.2.3

Type: Improvement Priority: Major
Reporter: Samuel Schmitt Assignee: Robert Šiška
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File content with a multiselect node.-1.jpg    
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

When a dialog provides a control of type "multiselect" the content created contains a subnode "multiselect" with the values -> see screenshot.

The problem is that the step "Update Primary type" will update the node and applies it the type "Area".. but it's not an area, it should stay a contentNode.

The goal here is to update the step "Update Primary type" of the migration process in order that it does not update these kind of nodes.
The difficulty is that only by analyzing the content you have no clue if this node is created by a "multiselect" and must stay a content node.

An analysis of the configuration is required before.

Idea:
The steps updating the content and the steps updating the configuration are more or less independent. If we want to keep them independent we should analyse the "old configuration" before running the migration of the content.

Analysis of the configuration:

  • find every paragraphs that have a control "mutliselect"
  • store the template and the name of the node created by multiselect in a map.

Update step "Update primary type":

  • when you find a node whose the template is in the map, you should skip the process over its child with the corresponding name.


 Comments   
Comment by Robert Šiška [ 29/Mar/13 ]

The contentNode in website is present only if it includes at least one entry. Otherwise, it's automatically deleted.
Therefore, all these are easily detected based on the fact that they only include number-labeled properties and have no subnodes except MetaData.

There are no other nodes (pre-mig) that match this characteristics. The only "false-positives" could be content created by custom controls which we don't want to migrate anyway.

Generated at Mon Feb 12 10:16:21 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.