Regression (v0.13.0): enum literal in conditional Visible/Editable expression mangled to a string → CE0117

[ako]

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.

• Affected: v0.13.0 (both --engine modelsdk (default) and --engine legacy)
• Introduced by: the conditional-visibility feature shipped in v0.13.0 (CONTAINER Visible expression produces CE0117 (needs repro; likely BSON serialization) #627)
• Reporter: field feedback (MES dashboards)

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.

[github-actions]

Issue Triage

Summary:
The issue reports a regression in mxcli v0.13.0 where enum literals in widget visible:/editable: expressions are incorrectly written as string literals, causing MxBuild to fail with error CE0117.

Checklist of required bug‑report information

Required info	Present?	Details
mxcli version	✅	v0.13.0 (both engines)
Mendix version	✅	Mendix 11.11.0 (verified)
Scenario (what the user was trying to do)	✅	MDL script with enum‑based visibility; runs mxcli exec then mx check
Expected output	✅	Expression stays as Mod.EquipmentStatus.Running; mx check reports 0 errors
Experienced output	✅	Expression written as 'Running'; mx check fails with CE0117
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

Missing information
Could you please attach the output of mxcli diag --bundle (or at least the relevant session log) so we can see the exact environment and any additional context? This will help us confirm the fix and ensure no other factors are involved.

Thank you for the detailed report! Once we have the diagnostic bundle, we can move forward with verifying the patch.

---

Automated triage via OpenRouter — workflow source