[MGNLMIGRATION-251] Migration fails to update available component if node name and node's name property don't contain the same name Created: 22/Jul/13 Updated: 23/Sep/13 Resolved: 23/Jul/13 |
|
| Status: | Closed |
| Project: | Migration 4.4 to 4.5 (closed) |
| Component/s: | Migration Task |
| Affects Version/s: | 1.2.3 |
| Fix Version/s: | 1.2.4 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Nils Breunese | Assignee: | Robert Šiška |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Date of First Response: |
| Description |
|
Before Magnolia 4.5 a node representing an available component (paragraph in prototype for instance) will often have the same name as the value the node's name property (node data). When this is not the case (which is valid AFAIK) TransformStkBasedTemplateMigrationTask#updateAvailableComponent(node) will look for the wrong component name. I believe the fix is to have this method use node.getProperty("name") (which is used when removing the old value!) instead of node.getName(). |
| Comments |
| Comment by Robert Šiška [ 23/Jul/13 ] |
|
Hello Nils, You're correct! The name of the node is now used only as a fallback, when the name property is not found. Thanks, |
| Comment by Nils Breunese [ 23/Jul/13 ] |
|
Thanks for the quick fix. Would you recommend using magnolia-4-5-migration-1.2.4-SNAPSHOT for now? |
| Comment by Robert Šiška [ 23/Jul/13 ] |
|
Sure! There is still a progress on the snapshot version, but it should always stay stable. |