Summary
Release regression in v0.13.0. An enum literal in a widget visible:/editable: expression is mis-encoded as a string, so MxBuild fails with CE0117 "Error(s) in expression." This blocks authoring enum-based conditional visibility (e.g. status pills) via mxcli.
Repro
create enumeration Mod.EquipmentStatus ( Running, Stopped );
create or modify persistent entity Mod.Equip (Name: String(100), Status: Mod.EquipmentStatus);
create page Mod.Pg (title: 'Pg', layout: Atlas_Core.Atlas_Default, params: { $Equip: Mod.Equip })
{
dataview dv (datasource: $Equip) {
container pill (visible: [$currentObject/Status = Mod.EquipmentStatus.Running]) {
dynamictext t (content: 'Running')
}
}
}
mxcli exec reports success, then mx check:
| Written |
Stored (v0.13.0) |
mx check |
[$currentObject/Status = Mod.EquipmentStatus.Running] |
$currentObject/Status = 'Running' |
❌ CE0117 |
Impact
- Pages written by ≤0.12 retain the enum literal and still build (existing dashboards report 0 errors).
- Re-running page generators on v0.13.0 mis-encodes every enum-based status pill → CE0117.
- The expression type-checker does not catch this at
mxcli check (it's a write-path mis-encoding, not a type error).
Root cause
conditionalExprToString (added with #627, mdl/visitor/visitor_page_v3.go) routed a qualified-enum QualifiedNameExpr to its default case → xpathExprToString, which converts a 3-part enum name to a string literal ('Running'). That conversion is correct for an XPath datasource constraint (evaluated at the database level, where enums are strings) but wrong for a client visibility/editability expression, which compares to the qualified enum value.
Fix
Add an explicit *ast.QualifiedNameExpr case to conditionalExprToString returning the qualified literal (Module.Enum.Value). The datasource where path (buildXPathString/xpathExprToString) is left untouched, so DB-level enums still correctly stringify to 'Value'. Applies to CREATE and ALTER (both use conditionalExprToString).
Fixed by commit 558856da1 (on the issues branch). Verified on Mendix 11.11.0, both engines: visibility enum stays Mod.EquipmentStatus.Running, datasource enum stays 'Running', mx check = 0 errors. Covered by a regression unit test and mdl-examples/bug-tests/680-enum-literal-conditional-visibility.mdl.
Recommendation
Patch release (v0.13.1) — this is a release blocker for enum-based conditional visibility authoring.
Workaround (until patched)
Don't re-run page generators on v0.13.0 for pages with enum-based visibility (existing pages keep the working enum literal). Set such visibility expressions manually in Studio Pro if a page must be regenerated.
Summary
Release regression in v0.13.0. An enum literal in a widget
visible:/editable:expression is mis-encoded as a string, so MxBuild fails with CE0117 "Error(s) in expression." This blocks authoring enum-based conditional visibility (e.g. status pills) via mxcli.--engine modelsdk(default) and--engine legacy)Repro
mxcli execreports success, thenmx check:[$currentObject/Status = Mod.EquipmentStatus.Running]$currentObject/Status = 'Running'Impact
mxcli check(it's a write-path mis-encoding, not a type error).Root cause
conditionalExprToString(added with #627,mdl/visitor/visitor_page_v3.go) routed a qualified-enumQualifiedNameExprto itsdefaultcase →xpathExprToString, which converts a 3-part enum name to a string literal ('Running'). That conversion is correct for an XPath datasource constraint (evaluated at the database level, where enums are strings) but wrong for a client visibility/editability expression, which compares to the qualified enum value.Fix
Add an explicit
*ast.QualifiedNameExprcase toconditionalExprToStringreturning the qualified literal (Module.Enum.Value). The datasourcewherepath (buildXPathString/xpathExprToString) is left untouched, so DB-level enums still correctly stringify to'Value'. Applies to CREATE and ALTER (both useconditionalExprToString).Fixed by commit
558856da1(on theissuesbranch). Verified on Mendix 11.11.0, both engines: visibility enum staysMod.EquipmentStatus.Running, datasource enum stays'Running',mx check= 0 errors. Covered by a regression unit test andmdl-examples/bug-tests/680-enum-literal-conditional-visibility.mdl.Recommendation
Patch release (v0.13.1) — this is a release blocker for enum-based conditional visibility authoring.
Workaround (until patched)
Don't re-run page generators on v0.13.0 for pages with enum-based visibility (existing pages keep the working enum literal). Set such visibility expressions manually in Studio Pro if a page must be regenerated.