[stagknee]

Closes #1618.

What it fixes

itemSelection: Single, Multi or None on a Data grid 2 or a Gallery, written by its widget key, was stored as PrimitiveValue with Selection left at its default. The grid had no selection, and a gallery kept its default Single. check, exec and mx check all stayed green.

How

• resolveSelectionValue (new, widget_selection_value.go) is shared by the engine, the explicit-key pass and check, so they can't disagree. It reads both the Selection: keyword and the property key, and validates the value against the SelectionTypes the template declares. PropertyTypeIDEntry.SelectionTypes is new and filled by the modelsdk loader; without it, the fallback is None/Single/Multi.

• New refusal, MDL-WIDGET50, in check and exec:

  • an invalid value (itemSelection: Bogus);
  • two spellings that disagree (Selection: Single, itemSelection: Multi). Picking a winner would be a guess, and "last pass wins" would depend on the order of two passes.

  Agreeing spellings, in any case (Multiple and Multi count as the same), are fine.

• The explicit-key pass now skips mapped selection keys by key, and writes an unmapped selection-typed key (for example combobox optionsSourceDatabaseItemSelection) as a selection. "selection" is added to explicitPassWritableTypes, so check no longer says that key will be dropped (MDL-WIDGET06).

• The Gallery click-ambiguity check (MDL-WIDGET36) now reads itemSelection too. Before, itemSelection: None plus onClick was reported wrongly.

• New refusal, MDL-WIDGET49, in check and exec: a definition constant that the script overrides by key on a widget that doesn't declare that property. Gallery 3.4.0 has no advanced, but gallery.def.json maps it to the constant false, so advanced: true was dropped. refuseUndeclaredMappedKey exempted every mapping with a constant. It now refuses an authored value that differs from the constant, and advanced: false still passes. Data grid 2 does declare advanced, and it's unchanged.

• Also included: CHANGELOG entries (Fixed), a finding in findings/mdl-executor/, a create-page skill note on selection by key, and mdl-examples/bug-tests/1618-datagrid-itemselection-by-key.mdl with a .fail.mdl companion.

Evidence

• Tests: widget_itemselection_by_key_test.go.

  • Against main, 22 tests and subtests fail: the stored selection is wrong, the bogus value and the conflict are accepted, an unmapped selection is written as a primitive, advanced: true is dropped, and the Gallery click rule fires wrongly. All pass with the fix.
  • The controls pass both ways: scalar keys (refreshInterval, pageSize, pagination), Data grid 2 advanced: true, and valid spellings.
  • The tests compare the whole stored widget object, with ids stripped.

• Real run (Mendix 11.12.5 scratch app), stored itemSelection, by key:

  Widget	v0.27.0	this branch
  datagrid Single	Selection None, PrimitiveValue Single	Selection Single
  datagrid Multi	Selection None, PrimitiveValue Multi	Selection Multi
  gallery None	Selection Single, PrimitiveValue None	Selection None
  gallery Multi	Selection Single, PrimitiveValue Multi	Selection Multi

  • The whole widget object is identical to the Selection: spelling for all four (it differed for all four on v0.27.0).
  • mx check reports 0 errors.
  • itemSelection: Bogus, the conflicting pair, and gallery advanced: true fail check -p (exit 1), and exec refuses and rolls back, also with --no-check.
  • alter page … set (itemSelection: Multi) was already refused loudly, so it's unchanged.

• Windows: go test ./mdl/executor/ ./mdl/backend/modelsdk/ shows the same pre-existing failures as main. go vet and gofmt are clean.

• Linux (golang:1.26.6-bookworm, ANTLR 4.13.2), on the branch rebased onto current main: make grammar build test check-mdl check-findings check-conformance check-migration-reference lint-go all pass.

Not in this PR

A survey of 12 widget templates shows the explicit-key pass still writes PrimitiveValue into property types that never hold one: Association, Image, Icon, Action, DataSource, Widgets and Object (for example, combobox attributeAssociation). Association by key has a real meaning (an association path) and is the same bug, but it needs entity resolution, so I left it for a follow-up. #1575's describe still prints selection through Selection:, which now matches what the key stores.

🤖 Generated with Claude Code