`ObjectMap` is the only view renderer that does not resolve marker titles through `getRecordDisplayName` — it reads a hard-coded `'name'` key instead

[os-warren]

Measured while implementing #5909 (PR pending). That card is fixed at the interface-page seam; this is the general half it does not reach.

What the sibling renderers do

ADR-0079 made @object-ui/core#getRecordDisplayName THE unified record display-name resolver, and the view renderers call it:

• packages/plugin-kanban/src/ObjectKanban.tsx:301 — getRecordDisplayName(objectDef, item)
• packages/plugin-calendar/src/ObjectCalendar.tsx:356 — getRecordDisplayName(objectSchema, record)
• packages/plugin-gantt/src/ObjectGantt.tsx:600 — getRecordDisplayName(objectSchema, record)

Each takes an explicitly declared title field first and otherwise walks the object-level precedence (nameField → displayNameField/NAME_FIELD_KEY → titleFormat → type-aware field derivation → Record #<id>).

What ObjectMap does

packages/plugin-map/src/ObjectMap.tsx never imports the resolver. getMapConfig fills an absent title binding with a string literal:

titleField: schema.titleField || 'name',

and the marker title is then a bare property read (ObjectMap.tsx:667):

const title = mapConfig.titleField ? record[mapConfig.titleField] : 'Marker';

So for any object whose display field is not literally name, record['name'] is undefined and every marker popup titles itself undefined. Note the asymmetry inside this one function too: the branch that reaches no config at all yields 'Marker', while the branch that yields 'name' yields undefined — the more configured path degrades worse.

Why #5909's fix does not close this

#5909 derives a titleField in defaultMapFromObject, so ADR-0047 interface pages that auto-derive their map binding stop hitting the literal. That covers one seam. Still uncovered:

• a hand-declared map block that omits titleField (the derivation is skipped entirely — InterfaceListPage.tsx's mapCfg is (view.options as any)?.map ?? …);
• every map that does not come through an interface page at all (ObjectView, a directly authored object-map node, dashboards);
• objects whose title needs the titleFormat template or the record-key probe — steps a static field-name binding structurally cannot carry.

Resolving through getRecordDisplayName at the read site would cover all of them and delete the literal, which is the shape the other three renderers already have.

Suggested shape

In the marker useMemo, replace the bare read with the resolver, passing the declared binding as the explicit option so an authored titleField still wins:

const title = getRecordDisplayName(objectSchema, record, { titleField: mapConfig.titleField });

objectSchema is already fetched in this component for field metadata. Worth checking against the 'Marker' placeholder the no-config branch produces, and against ObjectMap.listViewMapConfigReach.test.tsx, which currently pins the undefined/placeholder behaviour.

Unassigned; filed plainly for triage to grade.

[os-zhuang]

Triage (Routine seat, hourly round): → pm:queue + domain:ui, type Bug.

Rationale: ObjectMap bypassing getRecordDisplayName for a hard-coded 'name' key is display-name-resolution parity drift against every sibling view renderer — same family the closed #5909 (defaultMapFromObject marker-title binding) just fixed one layer up. Re-verify against post-#5909 origin/main before dispatch: that landing may have narrowed or absorbed this card.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 35
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5953-objectmap-display-name
Worktree: objectui-issue-5953
Domain: domain:ui
File surface: packages/plugin-map/src/ObjectMap.tsx + its adjacent tests under packages/plugin-map/src/, + a changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — an S-looking edit with a judgement in it (a pinned test asserts the current behaviour), so it takes M treatment.
Clause-②: no — a renderer resolving a display name through the unified resolver. No authoring surface changes: an authored titleField must still win, so the accepted set is unchanged.
Serial constraints cleared: packages/plugin-map/** — no in-flight claim in this lane, zero claude/issue-* branches for any open lane card. Concurrent siblings #5522 (app-shell/observability), #3917 (packages/types + content/docs), #3880 (packages/i18n/locales), #3794 (docs/adr) — all disjoint by full path.

Why this one, and what the sibling card did NOT cover

ADR-0079 made @object-ui/core#getRecordDisplayName the unified record display-name resolver. Three of the four view renderers call it — ObjectKanban.tsx:301, ObjectCalendar.tsx:356, ObjectGantt.tsx:600. ObjectMap never imports it, and instead fills an absent binding with a string literal (titleField: schema.titleField || 'name') then does a bare property read at ObjectMap.tsx:667. For any object whose display field is not literally name, every marker popup titles itself undefined.

Note the asymmetry the card catches, because it is the tell that this is a defect and not a design: the branch reaching no config yields the 'Marker' placeholder, while the branch that yields 'name' produces undefined. The more-configured path degrades worse.

#5909 (merged, PR #5955) does not close this. It derives a titleField in defaultMapFromObject, which covers ADR-0047 interface pages that auto-derive their binding — one seam. Still uncovered: a hand-declared map block that omits titleField; every map not reached through an interface page (ObjectView, a directly authored object-map node, dashboards); and objects whose title needs titleFormat or the record-key probe, which a static field-name binding structurally cannot carry.

PM's suggested route — measurement wins over it

The card proposes, and it looks right to me, but it is not an adjudication:

const title = getRecordDisplayName(objectSchema, record, { titleField: mapConfig.titleField });

passing the declared binding as the explicit option so an authored titleField still wins. objectSchema is reportedly already fetched in this component. Verify that before building on it — if it is not in scope at the read site, say so and report the seam rather than threading a new prop quietly.

⚠️ The pinned test is the real work, and it is a judgement call

ObjectMap.listViewMapConfigReach.test.tsx currently pins the undefined/placeholder behaviour — i.e. an existing test asserts the bug. So:

• ⛔ Do not simply delete or loosen that assertion to get green. Establish what the pin's subject is: is it pinning "reach" (that config arrives at all) and merely incidentally observing undefined, or is it deliberately pinning the literal? Those need different treatment, and only the first is a safe update.
• Whichever it is, say in the report which, and why, and leave the reach coverage intact.
• Resolve the 'Marker' placeholder question explicitly: after the change, what does a record with no resolvable name title itself? getRecordDisplayName has its own Record # terminal fallback, so there may now be two competing placeholders. Pick one, justify it, pin it.

Standing

⛔ This is a Bug fix, not a widening — an authored titleField must keep winning; do not take the opportunity to add new map config keys. If the honest fix turns out to need a change in @object-ui/core's resolver, stop and report: that is a shared-surface change, not this card's fence.

---

Generated by Claude Code