`DATAGRID … (DataSource: $Ctx/Module.Assoc)` writes the grid over the CONTEXT entity, so every column is mis-qualified → CE1613 ×N — passes `check --references`

[marclehane-creator]

Eval row 22; isolated on probe/p4-page.mdl:

CREATE PAGE Bench.Probe_CustomerOrders
( Title: 'Customer orders', Layout: Atlas_Core.Atlas_Default, Params: { $Customer: Bench.Customer } )
{
  DATAVIEW dvCustomer (DataSource: $Customer) { DYNAMICTEXT dtName (Content: '{1}', ContentParams: [{1} = $Customer/Name]) }
  DATAGRID dgOrders (DataSource: $Customer/Bench.Order_Customer)
  {
    COLUMN colOrderNo (Attribute: OrderNo, Caption: 'OrderNo')
    COLUMN colAmount  (Attribute: Amount,  Caption: 'Amount')
    COLUMN colStatus  (Attribute: Status,  Caption: 'Status')
  }
}

mxcli syntax page.datasource documents DataSource: $currentObject/Module.Assoc -- Over an association ("data from context") … list widget → to-many collection, so this is the documented
form. Rung 2: ✓ Syntax OK, ✓ All references valid, one MDL-WIDGET16 info. Exec: Created page.
Row 22's compiler: [CE1613] "The selected attribute 'Bench.Customer.OrderNo' no longer exists." at Columns (1/3) of data grid 2 'dgOrders', and the same for Amount and Status — the columns
were qualified against Customer (the path's source) instead of Order (its target: the
association Bench.Order_Customer is Order→Customer, so from a Customer the path yields Orders).
Either the writer must resolve the path's target entity for the grid, or check --references
must reject Attribute: OrderNo because Customer has no such attribute — it validated the
references and said they were valid.

Issue 83 — REFINED 2026-09-04 19:39Z: the defect is the PAGE-LEVEL path root, not by-association grids as such

Row 61 (a real app) built datagrid dgNotes (DataSource: $currentObject/AgencyAndProgram.ProgramNote_Program)
INSIDE a dataview and the compiler passed it with 0 errors — same topology as the failing fixture case.
Four probes on the fixture (the isolation probe) isolate the variable:

probe	where the grid sits	path written	check --references	exec	mx check
p4 (row 22)	page level, root = page parameter $Customer	$Customer/Bench.Order_Customer	exit 0	Created page	CE1613 ×3 — every column qualified against Bench.Customer
p4c	page level, root = $Customer	$Customer/Order_Customer (unqualified)	exit 0	REFUSED: "cannot resolve the destination entity of association "Order_Customer" … name the destination explicitly, e.g. Order_Customer/Module.Entity"	—
p4b	inside DATAVIEW dv (DataSource: $Customer)	$currentObject/Order_Customer	exit 0	Created page (written as $currentObject/Bench.Order_Customer)	clean
p4d	inside the dataview	$currentObject/Bench.Order_Customer	exit 0	Created page	clean

So: inside a dataview the writer resolves the association's far entity correctly, qualified or not. At
page level, with a page PARAMETER as the path root, the qualified form is accepted and written against
the WRONG entity (the parameter's), and the unqualified form is refused by exec's own resolver — i.e.
the resolver knows it cannot resolve the destination there, but the qualified spelling bypasses that
guard and writes the bad grid anyway. Ask: apply the same destination resolution (or the same refusal)
to the qualified page-level form; and let check --references report it, since the message exec
prints is exactly the diagnostic the check should have given. The decision line for CE1613 on grid
columns now says: inside a dataview $currentObject/Mod.Assoc is fine; at page level use
DATABASE Mod.Child WHERE [Mod.Assoc = $Param].

---

mxcli 0.20.0, Mendix 11.12.x, Windows 11. Found while evaluating a self-hosted agent loop that drives check → check --references → exec → mx check; each item above was reproduced on a fresh copy of the fixture or app named.