Analytics: a dataset dimension on a dotted relationship path (`crm_account.industry`) renders raw stored values — the same field as a local dimension renders its option labels

[os-zhuang]

Migrated from objectstack-ai/objectstack#5144 under the file-at-destination ruling (objectstack-ai/objectstack#7167, maintainer 2026-08-10). Originally filed 2026-08-04T06:05:10Z. The full prior thread — including triage rulings and hold/restart conditions — remains on the source issue and MUST be read before acting on this card.

---

Summary

A DatasetDimension whose field is a dotted relationship path gets no select-option resolution at all: the chart plots the raw stored values (education, finance, manufacturing). The same underlying field, reached as a local dimension on the object that owns it, resolves to its option labels (Education, Finance, Manufacturing).

Both render side by side on one dashboard, so the inconsistency is visible without leaving the screen.

Evidence

@objectstack/* 17.0.0-rc.1, fresh database, admin user. One dashboard (executive_dashboard), two widgets, both grouping on crm_account.industry:

Widget A — joined dimension → raw values

{ id: 'revenue_by_industry', type: 'donut',
 dataset: 'opportunity_metrics', dimensions: ['account_industry'], values: ['total_amount'] }

where the dataset declares

{ name: 'account_industry', label: 'Account Industry', field: 'crm_account.industry', type: 'string' }

renders its legend as:

education finance healthcare manufacturing software technology

Widget B — local dimension → option labels

{ id: 'accounts_by_industry', type: 'table',
 dataset: 'account_metrics', dimensions: ['industry'], values: ['annual_revenue_sum', 'account_count'] }

where the dataset declares

{ name: 'industry', label: 'Industry', field: 'industry', type: 'string' }

renders its rows as:

Education Energy & Utilities Finance Healthcare Logistics Manufacturing Software / SaaS Technology

Same field, same dashboard, same request. The only difference is field: 'crm_account.industry' vs field: 'industry'.

The option values on crm_account.industry are education / finance / … with labels Education / Finance / …, so widget A's output is exactly the stored column, unresolved.

Mechanism

The label resolver appears to look the select options up on the dataset's own object. For a dotted field, the options live on the related object (crm_account), the lookup misses, and the renderer falls through to the stored value. Nothing errors, so the widget just quietly displays database enum values to end users.

DatasetDimension has no key to help here — its whole surface is { name, label, field, type, dateGranularity } and type has no select member — so the dataset cannot declare "this dotted path is a picklist, resolve it against crm_account".

Why this is not a duplicate of objectstack-ai/objectstack#5076

objectstack-ai/objectstack#5076 is about analytics surfaces resolving option labels and then not applying the i18n bundle — the label is found, it is just the English one. That is widget B's behaviour.

This issue is the layer below: for a joined dimension the label is never resolved at all. Fixing objectstack-ai/objectstack#5076 alone would leave widget A still printing education, because there is no label in hand to translate.

Impact

Raw enum values reach end users on a dashboard. On a non-English deployment it is worse than English — education is neither the user's language nor a word they have ever seen in the UI, since every form and list shows the translated label.

Suggested fix

When a dimension's field is a dotted path, resolve the select options against the target object of the relationship rather than the dataset's base object, then apply the same option-label (and, per objectstack-ai/objectstack#5076, i18n bundle) resolution the local-dimension path already uses.

Related

• Analytics surfaces resolve select-option labels but never apply the i18n bundle — reports and dashboards show English while lists and forms show the translation objectstack#5076 — analytics surfaces resolve option labels but skip the i18n bundle.
• Report charts render the raw dataset measure name as the axis title, ignoring the measure's label — the same measure on a dashboard chart resolves correctly objectstack#5141 — report charts drop the dataset measure's label.
• View labels never resolve a translation — resolveViewLabel reads two fields the served view document does not have objectstack#4854 — view / report / dataset labels have no live translation path.

Filed from a downstream app (hotcrm-heimao), tracked there as issue #69.

[yinlianghui]

CLAIM (objectui whole-repo seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3) — dispatching now.

• Branch claude/issue-4053-dotted-dimension-labels, worktree objectui-issue-4053 (M container)
• Scope per the card's suggested fix: a dotted dimension field resolves its select options against the relationship's TARGET object, then flows through the same option-label resolution the local path uses (one resolver, not a dotted-path fork). The i18n-bundle half stays with objectstack#5076 — this card ends at "the label is in hand", per its own not-a-duplicate reasoning. Source thread objectstack#5144 is required reading per the migration header.

---

Generated by Claude Code

[yinlianghui]

ACCEPT (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4261, CI fully green in one converged pass.

The card asked for one site's fix; the measurement found TWO carrier sites and the fix landed as ONE shared resolver beside its sibling helpers, both consumers converged — the anti-drift shape, again. The dispatch's stop-condition (no new fetch layer on a guess) was answered the right way: target-object metadata rides the EXISTING GET /meta/object/:name channel through a caller-supplied loadObjectSchema (inheriting auth, base-URL rewrite, and draft-preview per #4121), memoized and seeded so sibling dimensions sharing a prefix fetch once and the base is never re-read. Two safety details deserve the record: relationship canonicalization mirrors the dataset designer's own resolveReferenceTo (all four spellings), and the walk is GATED on lookup/master_detail so a plain field's segment can never be coerced into an object name and speculatively fetched. Multi-hop came free, is pinned, and is proven non-hypothetical (ADR-0071's picker builds 2-hop paths that reach this resolver today). Scope held exactly at "the label is in hand" per the card's own dedup reasoning. The reverse verification's one prediction deviation (the fetch-trace assertion moving with the walk while the result assertion held) is reported, not smoothed. #4263 (the table/pivot/metric early-return leaves dotted dimensions raw on those widgets — a real user-visible remainder) is correctly NOT ridden — enabling the client net there adds a resolution those widgets never had, a design call — and the seat is queueing it now. Flipping ready + auto-merge.

---

Generated by Claude Code