Repository navigation
Record detail page renders address fields as raw JSON — the display registry has a location formatter but no address one #5019
Description
Summary
On a record detail page, a Field.address value renders as a stringified JSON object instead of a formatted address. The same field renders correctly in the create/edit dialog, so this is specific to the detail page's read renderer.
Observed on protocol ^17.0.0-rc.1 in a zh-CN console.
Evidence
The decisive comparison is same record, same page, same field group — one address field next to one location field:
| field | type | detail page (read) |
|---|---|---|
billing_address |
Field.address |
❌ {"street":"中策路 1 号","city":"杭州",…} |
office_location |
Field.location |
✅ 📍 30.2741, 120.1551 |
So the detail page's display renderer has a location formatter and lacks an address one, falling through to stringifying the object.
Meanwhile the create/edit dialog renders the same billing_address correctly as Street / City / State / ZIP / Country inputs.
This matches the shipped console bundle: the input registry carries both address: and location:; the display registry the detail page uses does not carry address.
The detail page's inline edit mode also shows the JSON.
Scope
Type-level, not object-specific. Confirmed by writing a value into a second object's address field through the API (crm_quote.billing_address) and seeing the same JSON rendering; reverted afterwards.
Any app with a populated Field.address on a detail page is affected.
Why there is no reasonable app-side workaround
Downstream consumers of ours evaluated and rejected each of these:
- Change the field to
text— destroys the structured value and breaks derivations that read sub-fields (in our case abilling_address.countryprojection that territory sharing rules match on), and loses the sub-field inputs that currently work. - Add a mirrored display-only field — puts two addresses on the page that can drift apart.
- Author detail-page sections — that changes where the value comes from, not the renderer that formats it.
Expected
The detail page's display registry resolves address the way it resolves location, rendering a formatted postal address.
Related
Same family as #4854 (view/report/dataset label translation path) in that it is a renderer-registry gap on one surface while a sibling surface handles it correctly, though the mechanism is different — this one is a missing formatter, not a missing i18n lookup.
Activity
os-zhuang commentedon Aug 5, 2026
分诊:入队
pm:queue(已挂repo:objectui)。packages/fields/src/index.tsx:1830的 display registry 显式把address映射到JsonCellRenderer(注释自述按 compact JSON 渲染),即 read 侧确实没有专用 address formatter,前提成立。修复即补一个 address 专用 read formatter(可参照location条目)。Field.addressvalues as raw JSON — the display registry has alocationformatter but noaddressone #5075 与本单同一缺陷(同 registry 缺口、同证据结构、同下游 hotcrm-heimao 追踪),已关为本单 duplicate,本单是唯一派发入口。相关但不同题:Console:AddressFieldsub-labels and placeholders are hardcoded English literals — an address field is untranslatable on any non-English console #5083(同 widget 的 input 侧 i18n)。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
Field.addressvalues as raw JSON — the display registry has alocationformatter but noaddressone #5075 as a duplicate of this issueos-zhuang commentedon Aug 10, 2026
Migrated to objectstack-ai/objectui#4037 under #7167 (file-at-destination ruling, maintainer 2026-08-10). Native GitHub issue transfer is not available to this session's credential, so the card was recreated at the destination; this thread stays as the authoritative history and is linked from the new card. Closing as not planned here — moved, not rejected.
Generated by Claude Code