Describe the bug
Same defect class as #7205 / #7206 / #7207 (an authored string written verbatim into a generated literal), fourth free-text key: the field label: (#6424). EdmIntentGenerator puts it on the property as widgetLabel unchanged (edm/EdmIntentGenerator.java:1222), the parser only refuses a blank label (IntentParser.validateLabels, :5395), and the Harmonia templates interpolate it raw:
ui/perspective/report/table-page.js.template:63 label: #if($property.widgetLabel)'${property.widgetLabel}'#else'${property.name}'#end
ui/perspective/report/chart-page.js.template:40 { name: #if($property.widgetLabel)'${property.widgetLabel}'#else ...
ui/perspective/manage/form-view.html.template:119 #set($label = $property.widgetLabel) ... :130 x-text="T('$projectName:${tprefix}.t.${property.dataName}', '${label}')"
ui/perspective/document/document-view.html.template:101/352/594 same #set($label/$alabel/$rolabel = $property.widgetLabel)
label: "Owner's copy" (or Customer's ref, "Qty (pcs)" is fine, Note's is not) closes the single-quoted JS literal: the report page's column list is a syntax error and the whole page is blank; in the form view the apostrophe ends the T() fallback argument inside an Alpine x-text expression, which throws at evaluation and - per the harmonia-ui guide - aborts the walk of the enclosing element. The guide already records this exact rule for task-form labels ("an authored label must be escaped where it is interpolated into a T() call - both the literal and the key"); the entity views never got it.
JsLiterals.escape exists since #7255 for the item-dialog seed and is the helper to route these through.
Expected
Every ${property.widgetLabel} / ${label} interpolation into a JS string or an Alpine expression in the Harmonia templates goes through the JS escape (a widgetLabelJs resolved once in ModelParameterProcessor, as widgetPatternJava / dataDefaultValueJs are), and IntentEmissionCoverageIT's fixture declares a label with an apostrophe so the generated pages are compiled/loaded with it.
Describe the bug
Same defect class as #7205 / #7206 / #7207 (an authored string written verbatim into a generated literal), fourth free-text key: the field
label:(#6424).EdmIntentGeneratorputs it on the property aswidgetLabelunchanged (edm/EdmIntentGenerator.java:1222), the parser only refuses a blank label (IntentParser.validateLabels,:5395), and the Harmonia templates interpolate it raw:label: "Owner's copy"(orCustomer's ref,"Qty (pcs)"is fine,Note'sis not) closes the single-quoted JS literal: the report page's column list is a syntax error and the whole page is blank; in the form view the apostrophe ends theT()fallback argument inside an Alpinex-textexpression, which throws at evaluation and - per the harmonia-ui guide - aborts the walk of the enclosing element. The guide already records this exact rule for task-form labels ("an authored label must be escaped where it is interpolated into aT()call - both the literal and the key"); the entity views never got it.JsLiterals.escapeexists since #7255 for the item-dialog seed and is the helper to route these through.Expected
Every
${property.widgetLabel}/${label}interpolation into a JS string or an Alpine expression in the Harmonia templates goes through the JS escape (awidgetLabelJsresolved once inModelParameterProcessor, aswidgetPatternJava/dataDefaultValueJsare), andIntentEmissionCoverageIT's fixture declares a label with an apostrophe so the generated pages are compiled/loaded with it.