ALTER SNIPPET/PAGE INSERT: pluggable-widget object-list children rejected; named-parameter-rooted list datasource passes check but fails build (CE7007)

[WouterHooglandTOF]

mxcli bug report (draft — needs lead developer approval before submitting)

mxcli version

v0.17.0 (2026-08-10T05:12:17Z)

Mendix version

10.24.20.105674

Context

Follow-up to a previous report (see the already-filed issue on this repo,
about MiniCompetitie module reconciliation and DOWNLOAD FILE). That
report's Bug #2 (DOWNLOAD FILE producing an empty action on fresh
microflow creation) is confirmed fixed in v0.17.0 — re-tested on the same
project, now produces a correct Download file activity.

While finishing the same feature, two more gaps surfaced, both specific to
ALTER SNIPPET/ALTER PAGE INSERT — the underlying constructs work fine
via CREATE [OR REPLACE] PAGE/SNIPPET, so this looks like an INSERT-path
limitation rather than a general grammar/serializer gap.

Bug A — pluggable-widget object-list child ("allowedfileformat") rejected inside ALTER ... INSERT

Reproduction

alter snippet MiniCompetitie.SNIP_NotitieComponent {
  insert after richText1 {
    pluggablewidget 'com.mendix.widget.web.fileuploader.FileUploader' fileUploaderTest (
      uploadMode: files,
      maxFileSize: 10
    ) {
      allowedfileformat allowedfileformatTest1 (ConfigMode: 'simple', PredefinedType: 'pdfFile')
    }
  }
};

mxcli check --references fails with a parse error:

Syntax errors found:
  - line 7:6 mismatched input 'allowedfileformat' expecting '}'
  - line 7:47 extraneous input '(' expecting the start of a statement (create, alter, drop, show, describe, …)
  - line 7:58 extraneous input ':' expecting the start of a statement (create, alter, drop, show, describe, …)
  - line 7:84 extraneous input ':' expecting the start of a statement (create, alter, drop, show, describe, …)

The identical pluggablewidget ... { allowedfileformat ... } block parses and
builds correctly when the widget is placed via create [or replace] snippet
(confirmed working elsewhere in this same project's pre-existing pages) — so
the grammar for the object-list child exists, but the INSERT operation's
grammar rule doesn't accept it as a valid child of a newly-inserted
pluggable widget. Removing the allowedfileformat block lets the bare
pluggablewidget insert succeed (syntax-wise), so the gap is specifically the
object-list-child-inside-INSERT combination.

Impact

Any pluggable widget whose configuration requires an object-list property
(allowed file formats, custom buttons, chart series, etc. — anything modeled
as a repeating child block rather than a flat key/value) cannot be fully
configured through ALTER ... INSERT. Workaround: configure those object-list
children in Studio Pro after the bare widget is inserted via mxcli, or build
the whole snippet/page via create or replace instead of insert.

Bug B — named-parameter-rooted list datasource inserted via ALTER ... INSERT fails at build time (CE7007), not at mxcli check

Reproduction

Snippet SNIP_NotitieBericht is declared as
(Params: { $Notitie: MiniCompetitie.Notitie }, ...). Association
MiniCompetitie.NotitieBijlage_Notitie exists (NotitieBijlage -> Notitie).

alter snippet MiniCompetitie.SNIP_NotitieBericht {
  insert after container68 {
    listview listViewTest (
      DataSource: $Notitie/MiniCompetitie.NotitieBijlage_Notitie,
      Class: 'notitie-item-bijlagen'
    ) {
      actionbutton btnDownloadTest (Caption: 'Download')
    }
  }
};

mxcli check --references reports success:

✓ Syntax OK (1 statements)
✓ All references valid
Check passed!

mxcli exec reports success (Altered snippet ...). But mxcli docker check
(full Mendix build) then reports:

[error] [CE7007] "No source variable has been selected for entity path
'NotitieBijlage_Notitie/Notitie'. Select the entity path again from an
available object." at List view 'listViewTest'

This matches this project's own master-detail-pages.md skill's documented
pattern (datasource: $currentObject/Module.Assoc — "or the explicit
datasource: association path form") exactly, except the root variable here
is a snippet's own declared $-parameter ($Notitie) rather than an
implicit $currentObject established by a surrounding DataView/ListView. The
ALTER ... INSERT codepath appears to build the association-path reference
without correctly wiring the "source variable" (Forms$AssociationSource's
start-object reference) when the root is a named snippet parameter — it's
accepted at parse/reference-check time (no error), but produces a semantically
incomplete widget that only fails at the full MxBuild compile.

Impact

mxcli check --references is not sufficient to catch this; only a full
docker check/mx check does. Anyone relying on mxcli check alone (e.g. in
a CI gate) would ship a broken list view. Workaround used here: build the
list view (or the whole snippet) in Studio Pro instead of via ALTER ... INSERT.

Suggested general fix direction

Both bugs point at the same likely root cause area: ALTER ... INSERT
appears to use a narrower/different code path for constructing new widget
subtrees than CREATE [OR REPLACE] PAGE/SNIPPET does, missing support for
(a) object-list child properties and (b) named-parameter-rooted association
datasources. If INSERT reused the same widget-tree builder that CREATE PAGE/CREATE SNIPPET use, both gaps would likely disappear at once.

Diagnostic bundle

Available on request (mxcli diag --bundle) — not attached here since both
repros above are self-contained and don't depend on project-specific state
beyond what's shown.