Split out of #491 so the platform-level gap is visible on its own and leadership can decide whether to (re-)escalate it to the upstream runtime repo. This is an upstream limitation, not app metadata.
The gap
The list-view data path (/api/v1/data/..., platform-objects) resolves {current_user_id} in filters — the "My Leads / My Tasks / My Deals" list views all work. The analytics path (dashboard widgets / dataset reports, /api/v1/analytics/...) resolves no user token at all: the literal string reaches the SQL WHERE, matches no owner, and the widget renders 0 for every viewer.
This was proven empirically before #491 and is documented in src/apps/crm.app.ts (My Work group note): a "My Day" dashboard was built and removed after a side-by-side test on one dashboard — {current_user} → 0, {current_user_id} → 0, no owner filter → 10,100,081. That note says "Filed upstream", but no issue link was recorded — hence this tracking issue.
(For contrast, the same analytics path DOES resolve the DATE_MACRO_TOKENS vocabulary — verified during #491 via the generated SQL in analytics responses — so this is specifically about user tokens.)
Impact on this app
To close this issue
When the analytics service learns to substitute {current_user_id} (parity with the list path), restore the personal widget: re-add filter: { owner: '{current_user_id}', is_closed: false } on the service_dashboard table widget and retitle it back to "My Open Cases by Priority".
Split out of #491 so the platform-level gap is visible on its own and leadership can decide whether to (re-)escalate it to the upstream runtime repo. This is an upstream limitation, not app metadata.
The gap
The list-view data path (
/api/v1/data/..., platform-objects) resolves{current_user_id}in filters — the "My Leads / My Tasks / My Deals" list views all work. The analytics path (dashboard widgets / dataset reports,/api/v1/analytics/...) resolves no user token at all: the literal string reaches the SQLWHERE, matches no owner, and the widget renders 0 for every viewer.This was proven empirically before #491 and is documented in
src/apps/crm.app.ts(My Work group note): a "My Day" dashboard was built and removed after a side-by-side test on one dashboard —{current_user}→ 0,{current_user_id}→ 0, no owner filter → 10,100,081. That note says "Filed upstream", but no issue link was recorded — hence this tracking issue.(For contrast, the same analytics path DOES resolve the DATE_MACRO_TOKENS vocabulary — verified during #491 via the generated SQL in analytics responses — so this is specifically about user tokens.)
Impact on this app
service_dashboard's "My Open Cases by Priority" widget silently showed 0 for everyone (it also misspelled the token as{current_user}, but the correct spelling would not have helped). The Views/pages/dashboards: dead references, unresolvable tokens, unreachable surfaces #491 branch re-scoped it to team-wide "Open Cases by Priority".my_open_caseslist view + a "My Cases" (我的工单) entry in the My Work nav group, joining My Tasks / My Deals / My Leads.To close this issue
When the analytics service learns to substitute
{current_user_id}(parity with the list path), restore the personal widget: re-addfilter: { owner: '{current_user_id}', is_closed: false }on the service_dashboard table widget and retitle it back to "My Open Cases by Priority".