Repository navigation
Analytics: the dataset widget's client-side dimension-label resolution is disabled for table / pivot / metric widgets, so a dotted dimension there still renders raw stored values #4263
Description
Found while implementing objectui#4053 (PR #4261). Filed rather than fixed there: the fix belongs to a different resolution owner and would change behaviour for every table widget, which is outside that card's scope.
What #4053 fixed, and where it stops
objectui#4053 fixed the client-side label safety net in DatasetWidget so a dotted dimension path (crm_account.industry) resolves its select options against the relationship's target object instead of the dataset's base object.
That safety net does not run for every widget type. packages/plugin-dashboard/src/DatasetWidget.tsx:
useEffect(() => {
if (isMetric || isTable) { setCategoryColors(null); setDimensionLabels(null); setCategoryOrder(null); return; }with isTable = widgetType === 'table' || widgetType === 'pivot'. The relabeling it feeds is applied only on the chart branch (const chartRows = relabelDimensions(state.rows, dimensionLabels)); the table/pivot branch renders state.rows as they arrived.
Why that leaves a gap
For a local dimension this is fine — the server resolves dimension display labels (ADR-0021), which is exactly why issue #4053's widget B (a table) rendered Education / Finance correctly. The client net is only a fallback for the case the server cannot resolve.
For a dotted dimension the server does not resolve the label either — that is the premise of #4053. So on a table or pivot dataset widget, a dotted dimension has neither resolution available and still renders the raw stored enum (education, finance), the same symptom #4053 reports for charts. #4053's fix does not reach it, because the effect returns before the lookup runs.
Not the same as the chart fix
Extending the net to tables is not "apply the resolution the local path uses" — for tables the local path's resolution is the server's, not this client-side one. Turning the client net on for table/pivot would add a resolution those widgets have never had, affecting every table dataset widget, not only dotted ones. That is a deliberate design call rather than a mechanical extension, which is why it is filed here instead of being ridden into PR #4261.
Suggested direction (for triage, not a decision)
Two shapes worth weighing:
- Run the existing client-side net for table/pivot as well, limited to dimensions whose resolution the server demonstrably skipped. Keeps one resolver; needs a rule for "demonstrably skipped" that does not double-translate an already-resolved label. Note
relabelDimensionsis documented as idempotent and value-keyed, which may make this cheaper than it looks. - Resolve it at the producer instead — have the analytics layer resolve dotted-path dimension labels server-side, which would fix charts, tables and pivots at once and let the client net go back to being a pure fallback. This is the contract-first shape and likely belongs in the framework repo.
Option 2 also subsumes the chart-side workaround over time.
Related
- objectui#4053 / PR fix(analytics): resolve a dotted dimension's select options against the relationship target #4261 — the chart-side fix this was found beside.
- objectstack#5076 — analytics surfaces resolve option labels but skip the i18n bundle (the layer above: label in hand, not translated).
- objectstack#5144 — the original thread for 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 #4053, with the triage ruling that scoped it to pure frontend resolution.
Activity
yinlianghui commentedon Aug 11, 2026
CLAIM + delegated direction ruling (objectui whole-repo seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3; veto window open) — dispatching now.Ruling: dotted-only gap-fill. The
isMetric || isTableearly-return stays for LOCAL dimensions (the server resolves those there — adding the client net for them would double-resolve and change widgets that work today); it opens ONLY for dimensions the server is silent on — the dotted ones — reusing #4261'sresolveDimensionFieldOptionsunchanged. The acceptance boundary: a local dimension on a table renders byte-identically to today (server's labels, pinned); a dotted dimension on a table/pivot/metric renders resolved labels (the gap, red-first); the non-dataset widget paths untouched.claude/issue-4263-dotted-dims-table-pivot, worktreeobjectui-issue-4263(S/M container)DatasetWidget.tsx— first edit waits until it is onorigin/main; NOTE objectui: pivot bucket id 把 null 维度值编码成占位符 U+2205,与「值恰好等于该占位符」的行仍会撞 #4056's agent is ALSO gated on fix(analytics): resolve a dotted dimension's select options against the relationship target #4261 and will then editDatasetWidget.tsx'sbuildPivot()— your surface is the label-net early-return and the dotted resolution path, THEIRS is bucket-id encoding; coordinate by file-region discipline and if the regions genuinely collide, the later-to-push rebases.Generated by Claude Code
yinlianghui commentedon Aug 11, 2026
ACCEPT — PM review of record (session
session_017Qqyix2QcnpUC9XeYVDzx3).PR #4273 fills exactly the gap the dotted-only ruling scoped: the label net's early return now opens for DOTTED dimension paths on table/pivot, reusing #4261's
resolveDimensionFieldOptionsunchanged, with onerelabelDimensionsat the top of the table branch feeding all four consumers (flat body,buildPivotinput, CSV, marginal totals).Points verified in review:
Educationheaders over—cells. Both sides take the relabel, pinned with server totals.buildPivot's bucket-id region untouched — only the argument at the call site changed; worst case is a one-line rebase whichever lands second.Flipping ready + auto-merge.
Generated by Claude Code
fix(dashboard): resolve a dotted dimension's labels on table and pivo…
fix(dashboard,report): localize a LOCAL select dimension on table/piv…