Skip to content

Tab page CaptionParams and Visible: pass check and exec, then are silently not written #1465

Closed
ako/mxcli
#1197

Description

@AlvinnYeo

Summary

On a tabpage, CaptionParams: (...) and Visible: <expression> are accepted by check -p --references and by exec, with no MDL-WIDGET07 warning. Neither is stored. The caption is written as literal text (the tab shows Due · {1}), and the tab page gets no conditional visibility. mxbuild then builds clean, so nothing tells the user that anything was lost. We found it only by reading the unit back after exec.

Visible: on a container in the same script was stored correctly.

Environment

Steps to reproduce

The minimal script below is reduced from the field script and passes mxcli check (grammar only). We have not yet run this exact script end to end on a blank project.

mdl 1;
create module MyModule;
create persistent entity MyModule.PortalSummary (DueCount: Integer, ShowTabB: Boolean);
create page MyModule.Portal (
  Params: ($Summary: MyModule.PortalSummary),
  Title: 'Portal',
  Layout: Atlas_Core.Atlas_Default
) {
  dataview dvSummary (DataSource: $Summary) {
    tabcontainer tabs1 {
      tabpage tpA (Caption: 'Due · {1}', CaptionParams: ({1} = DueCount)) {
        dynamictext txtA (Content: 'Tab A')
      }
      tabpage tpB (Caption: 'Tab B', Visible: $currentObject/ShowTabB) {
        dynamictext txtB (Content: 'Tab B')
      }
    }
  }
};
  1. mxcli check script.mdl -p App.mpr --references
  2. mxcli exec script.mdl -p App.mpr
  3. mxcli -p App.mpr -c "describe page MyModule.Portal", and/or read the page unit's BSON.
  4. mx check App.mpr

Expected

One of:

  • both properties are written (caption parameters bound, tab page visibility set), or
  • check refuses the ones mxcli cannot write (MDL-WIDGET07 or similar), so the user knows before exec.

Hypothesis, not checked against the metamodel: a tab page's caption may be plain translatable text with no parameters in Mendix (the badge is the templated part). If so, CaptionParams should be refused rather than written.

Actual

  • check and exec pass with no warning; mx check reports 0 errors.
  • The stored caption is the literal Due · {1}, and the running app shows it that way.
  • Tab page tpB has no ConditionalVisibilitySettings: the attribute name ShowTabB occurs 0 times in the page unit. The tab is always shown.

Workaround used

Plain captions with the count shown as a line inside each tab. The flag-dependent content moved out of the tab into a container (Visible: $currentObject/ShowTabB), which is stored correctly.

Suggested fix

Write Visible: on tab pages the same way as on containers. For CaptionParams, write it if the metamodel allows it, otherwise refuse it in check. More generally, any property the parser accepts on a widget but the builder does not write should raise MDL-WIDGET07.

Activity

  1. github-actions commented on Oct 13, 2026

    @github-actions

    Issue Triage

    Summary:
    The issue reports that CaptionParams and Visible properties on a tabpage are accepted by mxcli check and exec but are not written to the MPR, causing silent data loss.

    Checklist of required bug‑report information

    Required info Present? Details
    mxcli version ✅ mxcli v0.25.0 (2026-10-05), macOS arm64
    Mendix version ✅ Mendix 11.14.0 Beta project
    Scenario (what the user was trying to do) ✅ MDL script creating a page with a tabcontainer, CaptionParams and Visible on tabpages; steps to reproduce via check, exec, describe
    Expected output ✅ Either both properties are written correctly or check should refuse them with an MDL‑WIDGET07 warning
    Experienced output ✅ check and exec pass with no warning; stored caption is literal text (Due · {1}); tab page lacks conditional visibility; mx check reports 0 errors
    AI bug report (session log or diag --bundle) ❌ Not attached; reporter says they can share session‑log lines on request but none provided

    Missing information
    Please provide at least the relevant session‑log output (or run mxcli diag --bundle and attach the bundle if possible) so we can see exactly what mxcli did during the check and exec steps.

    Once the log is shared, we’ll be able to investigate further. Thank you for the detailed report!


    Automated triage via OpenRouter — workflow source

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions