fix: mappings skipped attributes inherited from a parent entity (#703)

[ako]

Fixes mendixlabs/mxcli#703 — the mapping half of the #765 umbrella, following mendixlabs#758 (access rules).

Problem

Mendix inheritance is multi-table: a child adds attributes to its parent's, and all the parent's are members of the child. A mapping element bound to one must reference the entity that declares it. The builder prefixed the entity being mapped, unconditionally:

attr := def.Attribute
if parentEntity != "" && !strings.Contains(attr, ".") {
    attr = parentEntity + "." + attr      // always the CHILD
}

So every inherited field produced a reference to an attribute that entity doesn't have. Studio Pro shows the field unmapped — the reported symptom — and mx check reports CE1613 "The selected attribute … no longer exists".

A second, quieter defect sat next to it. resolveAttributeType scanned only the entity's own attributes and fell through to a "String" default, so an inherited Boolean or DateTime element carried the wrong DataType even once the reference was correct. Worth noting because fixing only the reference would have looked like a complete fix while silently mistyping every inherited non-String field.

That function also matched entities by name across every domain model, ignoring the module — a same-named entity elsewhere could win. It now resolves the module by name.

Approach

Both the import and export builders carried the same two lines; both are fixed. They route through the generalization walk added for mendixlabs#758, generalised here into:

• ResolveMemberRef — the declaring-entity reference for a member
• ResolveMemberType — the member's type, found up the chain

Each falls back to the previous behaviour when the member can't be resolved, so an unresolvable name behaves exactly as before rather than changing shape. EntityMembersFor now takes the backend directly, since the mapping builders hold no ExecContext.

Verification

End-to-end on a real 11.12.2 project — one own and two inherited attributes, mapped in both directions:

	reference	DataType
before	Map703.Contract.DocName → CE1613	StringType
	Map703.Contract.Confidential → CE1613	StringType ❌
after	Map703.DocumentBase.DocName	StringType
	Map703.DocumentBase.Confidential	BooleanType ✅

mx check → 0 errors (was 2 × CE1613). Full ./... suite green.

Both halves mutation-checked — including one detail worth flagging for review: my first mutation of the type fix passed, because the unit test exercised ResolveMemberType directly while the mutation disabled its call site in resolveAttributeType. I added a test at the call site, which does fail under that mutation. A resolver test proves the resolver, not that anything uses it.

Repro script: mdl-examples/bug-tests/703-mapping-inherited-attributes.mdl (covers import and export).

Documentation

Inheritance was unmentioned in every mapping doc, so this adds it to mxcli syntax import-mapping, the json-structures-and-mappings skill, and docs-site create-import-mapping.md.

Generalisable lesson (recorded in the symptom table)

When one rule has several call sites, a fix at one proves nothing about the others — grep for the pattern (range entity.Attributes, parentEntity + ".") rather than the reported symptom. This is the third site of the same declaring-entity rule; mendixlabs#451's was already fixed independently in the microflow path, which is exactly why mendixlabs#765 was filed as an umbrella.

With this, mendixlabs#765's three covered issues are all closed: mendixlabs#758 (access rules), mendixlabs#703 (mappings), mendixlabs#451 (change-object writer).

---

Generated by Claude Code