OrderLineFieldValues column serialized as escaped text in live integr…

[DWDBE]

Observed behaviour

When the Include custom order line fields in request setting is enabled, the OrderLineFieldValues column inside the EcomOrderLines table of the outgoing order XML contains HTML-escaped text instead of proper nested XML:

The ERP receives a literal string rather than structured XML, making the field unparseable.

Expected behaviour

MyField SomeValue

Root cause

The bug is in OrderXmlGenerator.cs at line 339:

AddChildXmlNode(itemNode, "OrderLineFieldValues", OrderLineFieldValuesToXml(orderline.OrderLineFieldValues).InnerXml);

OrderLineFieldValuesToXml() correctly builds an XmlDocument with proper XML nodes. .InnerXml is then called on it to extract the XML as a string. That string is passed to AddChildXmlNode(), which assigns it via:

node.InnerText = nodeValue; // XmlGenerator.cs

InnerText treats its input as plain text and XML-escapes all special characters (< → <, > → >). The result is the XML structure rendered as an escaped string rather than embedded XML nodes.

Fix

At the call site in OrderXmlGenerator.cs, bypass AddChildXmlNode and use XmlDocument.ImportNode to deep-copy the XML nodes into the parent document directly:

// Replace line 339: // AddChildXmlNode(itemNode, "OrderLineFieldValues", // OrderLineFieldValuesToXml(orderline.OrderLineFieldValues).InnerXml); var fieldValuesNode = itemNode.OwnerDocument.CreateElement("column"); fieldValuesNode.SetAttribute("columnName", "OrderLineFieldValues"); fieldValuesNode.AppendChild( itemNode.OwnerDocument.ImportNode( OrderLineFieldValuesToXml(orderline.OrderLineFieldValues).DocumentElement, deep: true)); itemNode.AppendChild(fieldValuesNode);

ImportNode copies the element tree into the target document's namespace as real XML nodes, so the output is properly structured XML rather than escaped text.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[MatthiasSort]

Code review

Correct, well-targeted fix for a genuine bug. AddChildXmlNode assigns values via XmlElement.InnerText (which XML-escapes), so the old OrderLineFieldValuesToXml(...).InnerXml round-trip produced escaped text — the new ImportNode(..., deep: true) deep-copy produces proper nested XML matching the sibling <column columnName="..."> structure. A couple of non-blocking comments:

1. Maintainability — the fix hand-rolls the <column columnName="…"> convention that belongs to AddChildXmlNode

The new block re-implements CreateElement("column") + SetAttribute("columnName", …) + AppendChild(…) inline — the exact element-construction contract that XmlGenerator.AddChildXmlNode owns and applies to every other column on the order line. The only reason it can't reuse the helper is that AddChildXmlNode takes a string value and escapes it; it has no overload for embedding an XmlNode.

As a result the <column> wrapper convention now lives in two places. If the base helper's column shape ever changes (a new default attribute, a namespace, a renamed columnName), this one site silently diverges and OrderLineFieldValues gets emitted differently from its siblings — the same class of inconsistency this PR is fixing.

A deeper fix keeps the convention in one place — add an overload to the shared infrastructure:

protected static void AddChildXmlNode(XmlElement parent, string nodeName, XmlNode nodeValue,
    bool isInformationalOnly = false, bool isCustomField = false)
{
    // same column + attribute construction as the string overload
    node.AppendChild(parent.OwnerDocument.ImportNode(nodeValue, deep: true));
    parent.AppendChild(node);
}

then call:

AddChildXmlNode(itemNode, "OrderLineFieldValues",
    OrderLineFieldValuesToXml(orderline.OrderLineFieldValues).DocumentElement);

2. Minor — no regression test

The bug is a pure serialization issue and a .Tests project exists. A small test asserting the OrderLineFieldValues <column> contains a child <OrderLineFieldValueCollection> element (rather than escaped text) would lock in the fix cheaply.

Reasonable to merge as-is if you prefer to keep the change minimal.