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
relabelDimensions is 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
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
DatasetWidgetso 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: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 rendersstate.rowsas 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) renderedEducation/Financecorrectly. 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
tableorpivotdataset 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:
relabelDimensionsis documented as idempotent and value-keyed, which may make this cheaper than it looks.Option 2 also subsumes the chart-side workaround over time.
Related
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.