Repository navigation
Address fields render as raw JSON on the record detail page #664
Description
Activity
分诊(PM 循环第 1 轮扫检,会话
session_01Rvtsew6XgsSjxVa59HRPRK):落地层不在本仓,加upstream:objectstack,不入pm:queue。核验:
objectstack仓的packages/console只是发布包装(无源码),记录详情页的字段渲染器在 Console 前端(objectui)。hotcrm 侧Field.address()的作者姿态正确(issue 正文的双版本对照也证明了与 rc.2 升级无关),本仓没有可改动的代码 —— issue 正文的判断(「HotCRM-local workaround 拆平字段是错误的取舍」)采纳:不做本地绕过。待办(PM 跟进):在上游归档「
address字段类型缺 detail-page 格式化器」的 issue(附本 issue 的复现与截图路径),拿到链接后回填到这里。在上游修复发版前,本 issue 保持 open 作为跟踪单。
Generated by Claude Code
上游查重结果:已存在完全对应的平台 issue —— objectstack-ai/objectstack#5019(「Record detail page renders
addressfields as raw JSON — the display registry has alocationformatter but noaddressone」),且已在上游 PM 队列中。无需新档。Blocked-by: objectstack-ai/objectstack#5019。上游修复发版并被本仓吸收后,按本 issue 的复现步骤回验并关闭。
Generated by Claude Code
[17.0-rc2验收复核] 测试组 A6 在
hotcrm@0899b4f + @objectstack 17.0.0-rc.2全新 dev 环境实测:问题依旧存在,原样复现。- 客户详情页(如 seeded Vertex Analytics / Wayne Enterprises)Contact Information 分组的 BILLING ADDRESS 仍渲染原始 JSON:
{"street":"600 Congress Avenue, Floor 14","city":"Austin","state":"TX","postalCode":"78701",…},为整页最宽字段;相邻 BILLING COUNTRY(text)正常显示US。 - 走查 17 个 crm_* 对象详情页,address 型字段仅 crm_account(billing/shipping)受影响,现象与本单描述逐字一致。
- 表单侧不受影响:新建/编辑表单里 address 拆成 Street/City/State/ZIP/Country 子输入,正常可编辑 —— 缺的只是详情页的格式化渲染器,与本单「Console (objectui) 层缺 address formatter」的定位一致。
补充一个同族线索:平台仓已有 open 单 objectstack#5083(AddressField 子标签硬编码英文)、objectstack#5143(AddressField ZIP 绑定
zipCode与存储postalCode不一致),说明 AddressField 在 console 侧仍在补齐,详情页 formatter 缺失建议一并在平台侧跟进。
Generated by Claude Code
- 客户详情页(如 seeded Vertex Analytics / Wayne Enterprises)Contact Information 分组的 BILLING ADDRESS 仍渲染原始 JSON:
Re-measured on
@objectstack/*17.0.0-rc.6 during the rc.5 → rc.6 upgrade (#1059, PR #1066). The console now ships an address formatter — which is what this card concluded was missing, and it landed where the card predicted it belonged (upstream, not here).@objectstack/console's bundledui-componentsasset carries anAddressFieldwhose readonly branch formats the parts rather than stringifying the object:h = e => [e.street, e.city, [e.state, postal(e)].filter(Boolean).join(' '), e.country] .filter(Boolean).join(', ') if (readonly) { let s = h(value); return <span className="text-sm">…
So
crm_account.billing_addressshould now render as500 Howard Street, Suite 400, San Francisco, CA 94105, USrather than the JSON blob. The component also normaliseszipCode→postalCode, which suggests the value shape this app writes is the one it expects.This also settles the card's open question — "worth confirming which layer owns the
addressformatter before deciding whether this is a HotCRM issue at all". It is Console's, and no HotCRM-local workaround is needed.Field.address()onbilling_address/shipping_addressstays as authored, and the "split the address into flat text fields" trade the card flagged as wrong can stay untaken.Scope note — not browser-verified. This is a static read of the shipped component, not the reproduction steps in this card. Someone should do the
pnpm demo:reset→pnpm dev→ open a seeded account pass before closing, because a formatter existing in the bundle and the detail page actually routing anaddressfield to it are two different claims, and this card was originally filed on precisely that gap.
Generated by Claude Code
GA browser probe — NOT REPRODUCIBLE on 17.0.0 GA · closing
This is the browser verification the rc.6 comment explicitly deferred ("a formatter existing in the bundle and the detail page actually routing an
addressfield to it are two different claims"). Both claims now hold.Version —
@objectstack/*17.0.0 GA, all 50 installed packages including@objectstack/console(checkednode_modules/@objectstack/console/package.json→17.0.0, not an rc). hotcrm @d4ddee0.Probe — wiped
.objectstack/data,pnpm build,objectstack dev -p 4003 --seed-admin, real Chromium 141 driven by Playwright, signed in through the console UI asadmin@objectos.ai, opened
/_console/apps/app.objectstack.hotcrm/crm_account/record/JcMPk-7IMMkoHY8X— seeded Acme Corporation (ACC-000001), i.e. the exact record and the exact stored address this card was filed on:{"street":"500 Howard Street, Suite 400","city":"San Francisco","state":"CA","postalCode":"94105","country":"US"}Result — the Contact Information group renders, label-anchored from the live DOM:
BILLING ADDRESS | 500 Howard Street, Suite 400, San Francisco, CA 94105, USByte-for-byte the comma-joined form the rc.6 static read predicted. Neighbouring
BILLING COUNTRYstill rendersUSindependently, exactly as the original report described.What I would have seen if the defect were still present
Stated before running, so the green is falsifiable rather than decorative:
check if defect still live measured on GA raw JSON blob ( {"street"/"postalCode") anywhere in page textpresent absent exact string 500 Howard Street, Suite 400, San Francisco, CA 94105, USabsent present record identity guard — page really rendered this record — Acme CorporationpresentThe third row matters: a blank or unpopulated field would also have shown "no raw JSON", and that would have been a vacuous pass. The address is populated and formatted.
Screenshot —
664-address-closeup-GA.png: the Contact Information card with PHONE / WEBSITE / BILLING ADDRESS / BILLING COUNTRY in one frame, BILLING ADDRESS reading500 Howard Street, Suite 40…(clamped by column width in the visual; the full string is in the DOM text above).Cosmetic note, not a defect and not re-opening anything: the value is CSS-truncated to its column, so the long form shows an ellipsis. The original complaint was "widest field on the page"; it is now clamped like its neighbours.
Fixed upstream in console, exactly where this card predicted it belonged — no HotCRM-local change was needed and the "split the address into flat text fields" trade stayed untaken.
Blocked-by: objectstack-ai/objectstack#5019is discharged. Removingpm:blockedin the same label write as this close.Probed under #1154 (parent #1150).
Generated by Claude Code
Found while browser-verifying the ObjectStack 17.0.0-rc.2 upgrade (#663). Filing it separately because it is not caused by that upgrade — see the attribution below.
What happens
On an account detail page, the
billing_addressfield renders its stored value verbatim as JSON instead of as a formatted address:The neighbouring
BILLING COUNTRY(a plain text field) renders normally asUS, so the page itself is fine — it is theaddressfield type's detail-page renderer that has no formatter and falls back to stringifying the object.Why it matters
crm_account.billing_addressis authored withField.address(...), i.e. a structured postal address — the type exists precisely so the platform knows the value has parts. A business user reading an account record sees a JSON blob where they expect a mailing address, and it is the widest field on the page. The same field type is used on other objects, so any record carrying an address has the same presentation.Note this is presentation only: the stored value is correct and well-formed, and the API returns it correctly.
Reproduce
pnpm demo:resetthenpnpm devadmin@objectos.ai/admin123)/_console/apps/app.objectstack.hotcrm/crm_account/record/<id>→ Contact Information groupNot caused by the 17.0.0-rc.2 upgrade
Measured rather than assumed. I booted an
origin/mainworktree (still on 17.0.0-rc.1) on port 4002 alongside the rc.2 server on 4001 and read the same field on the same seeded account through the same Chromium session:origin/main){"street":"500 Howard Street, Suite 400","city":"San Francisco","state":"CA","postalCode":"94105","country":"US"}So this predates the upgrade and is longstanding.
Where the fix likely belongs
Probably not in this repo: the detail-page field renderer is Console (objectui) territory, and HotCRM's side (
Field.address()oncrm_account.billing_address/shipping_address) looks correctly authored. Worth confirming which layer owns theaddressformatter before deciding whether this is a HotCRM issue at all or should move upstream — if the renderer is missing entirely, the upstream fix benefits every app, and a HotCRM-local workaround (splitting the address into flat text fields) would be the wrong trade.