Analytics/dashboard query path resolves no user token — personal ("my …") dashboard widgets are impossible

[yinlianghui]

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.)

⚠️ The headline above is not quite the mechanism, per the upstream review of objectstack#12376. Token resolution had already landed in @objectstack/core after 17.1.0; what actually produced the measured 0 was two narrower holes — the direct AnalyticsService.query / generateSql door resolved nothing (so the SQL strategy bound the literal while the ObjectQL strategy resolved via the engine), and the dataset-scope channel handed strategies an unresolved copy of the filter which was ANDed beside the resolved one, producing an unsatisfiable owner = $viewer AND owner = '{current_user_id}'. That second one is why the shape was a hard 0 rather than a partial result. The defect was real; the one-line diagnosis in this card was incomplete.

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".
• The personal use-case is served through list views instead: Views/pages/dashboards: dead references, unresolvable tokens, unreachable surfaces #491 adds a my_open_cases list view + a "My Cases" (我的工单) entry in the My Work nav group, joining My Tasks / My Deals / My Leads.

To close this issue

Once the Restart-when: predicate above is met, restore the personal widget on the service_dashboard table widget and retitle it back to "My Open Cases by Priority".

⚠️ Use owner_id, not owner. Since #548/#677 the owner column no longer exists and the spelling in the original instruction fails with no such column: owner (measured). Copying that line verbatim will misfire.

⭐ Two behaviour changes arrive with the fix, and both help: an unresolvable placeholder now refuses loudly (FILTER_TOKEN_UNKNOWN / FILTER_TOKEN_UNRESOLVED, HTTP 400) instead of charting a plausible zero — so a broken restore will look like an error rather than an empty widget — and the {current_user} misspelling this card records is now caught with a near-miss suggestion rather than silently rendering 0.

⚠️ Verify the restore by having two different reps see different rows. {current_user_id} is presentation scope, not an access boundary — that is the frozen vocabulary's own declaration (objectstack#3594). Row-level security owns the guarantee that one rep cannot reach another's cases; this token only scopes what a widget shows.

[yinlianghui]

rc.2 retest: 已解除 — {current_user_id} resolves to a bound SQL parameter; unknown tokens fail loudly

Retested on @objectstack/* 17.0.0-rc.2 (current main), by capturing the console's live analytics payload from the Service Overview dashboard and replaying it with variations (the query endpoint takes datasetName + selection, discovered from the real capture):

runtimeFilter	rows	generated SQL
{is_closed:false} (control)	32	WHERE is_closed = $1
{owner:"<literal admin id>", is_closed:false}	32	WHERE (owner = $1 AND is_closed = $2)
{owner:"{current_user_id}", is_closed:false}	32	WHERE (owner = $1 AND is_closed = $2) — token substituted to a bound param
{owner:"{current_user}", …}	error	ANALYTICS_QUERY_FAILED: Unresolvable filter placeholder "{current_user}". Did you mean "{current_user_id}"?

Cross-check: all 32 open cases are owner=admin, so token ≡ literal ≡ control is the correct outcome — an unresolved literal string would have matched 0 rows (the rc.0 failure mode). And the unknown-token case now fails loudly with a suggestion instead of silently matching nothing.

So the platform half of this issue is resolved: the analytics query path does resolve the user token. The CRM half remains open work — service.dashboard.ts still deliberately ships the team-wide table with the source comment explaining personal widgets are impossible, and restoring a "My Open Cases by Priority" widget is exactly the closure task for this issue. That's a small code PR now that the platform supports it.

Evidence: analytics_captures.json in the acceptance run's w2b directory.

---

Generated by Claude Code

[yinlianghui]

[17.0-rc2验收复核] 结论:部分复现已解除 —— 平台半(用户 token 解析)已修;CRM 半(恢复个人 widget)仍待收尾

证据:独立 dev server(端口 4091)POST /api/v1/analytics/dataset/query(case_metrics,admin token,30 条未关闭工单全部 owner=admin):

runtimeFilter	rows	生成 SQL
{is_closed:false}(control)	30	WHERE is_closed = $1
{owner_id:"<literal admin id>", is_closed:false}	30	WHERE (owner_id = $1 AND is_closed = $2)
{owner_id:"{current_user_id}", is_closed:false}	30	同上 —— token 已替换为绑定参数
{owner:"{current_user}",…}	报错	ANALYTICS_QUERY_FAILED: Unresolvable filter placeholder "{current_user}". Did you mean "{current_user_id}"?

token ≡ literal ≡ control,且未知 token 响亮报错并给出纠正建议 —— rc.0 的「字面串进 SQL 永匹配 0」失败模式已消失。

两个恢复 widget 时的注意事项:

1. 字段名要用 owner_id:Ownership model mismatch: app-authored owner lookups vs the platform's owner_id — reassigning Owner in the UI does not move record access #548/fix: bug 批次修复(PM 派发循环)— #606 #673 #610 #548 #678 #650 已落地 #677 之后 owner 列已不存在,{owner: …} 会直接 no such column: owner(实测)。正文里的恢复指引写的是 filter: { owner: … },照抄会踩坑。
2. src/dashboards/service.dashboard.ts:268-280 仍是 team-wide "Open Cases by Priority",注释仍引用本单 —— 恢复 "My Open Cases by Priority" 即本单的收尾 PR。

环境:hotcrm@0899b4f + @objectstack 17.0.0-rc.2

建议:平台前提已过时;本单保留仅为 CRM 侧恢复个人 widget 的小 PR(按上面两点),落地后可关。

---

Generated by Claude Code

[hotlong]

Not closed — the platform half is fixed, but this card's own stated closing condition is unmet.

This card was on the direct-close list for the GA close-out bookkeeping sweep (#1151, group 3), which authorised closing it on its recorded rc.2 retest readings. Read in full, those readings explicitly withhold the close, so it stays open. Recording why.

What the readings do establish

The platform gap is closed. On @objectstack/* 17.0.0-rc.2, replaying the console's live analytics payload against case_metrics with variations:

runtimeFilter	rows	generated SQL
{is_closed:false} (control)	30	WHERE is_closed = $1
{owner_id:"literal admin id", is_closed:false}	30	WHERE (owner_id = $1 AND is_closed = $2)
{owner_id:"{current_user_id}", is_closed:false}	30	same — token substituted to a bound parameter
{owner:"{current_user}", …}	error	ANALYTICS_QUERY_FAILED: Unresolvable filter placeholder "{current_user}". Did you mean "{current_user_id}"?

Token ≡ literal ≡ control is the correct outcome (all open cases are owner=admin); an unresolved literal string would have matched 0 rows, which was the rc.0 failure mode. Unknown tokens now fail loudly with a suggestion.

Source: rc.2 retest · independent re-read

Why that is not enough to close this card

1. This card's body defines its own closing condition, and it is a code change that has not happened. The "To close this issue" section reads:

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".

The antecedent is now true. The consequent has not been done — src/dashboards/service.dashboard.ts:268-280 still ships the team-wide "Open Cases by Priority", with a source comment still pointing at this issue.

2. Both readings say so themselves, and neither recommends closing now. 「平台半(用户 token 解析)已修;CRM 半(恢复个人 widget)仍待收尾 … 落地后可关」 — close after it lands. The other: "The CRM half remains open work … restoring a 'My Open Cases by Priority' widget is exactly the closure task for this issue."

Closing on the platform reading alone would discard a named, unfinished deliverable that no other card carries — the source comment in service.dashboard.ts would then point at a closed issue.

3. The restore instruction in the body is itself stale and will misfire if copied. The rc.2 reading flagged this: since #548/#677 the owner column no longer exists, and {owner: …} fails with no such column: owner (measured). Whoever does the restore must use owner_id, not the owner spelling written in this card's body.

What would close it

The small CRM PR the readings describe: restore the personal widget on service_dashboard using owner_id, retitle it, drop the stale source comment, and confirm it renders per-viewer. That is a code change and therefore outside #1151's bookkeeping mandate.

This card is no longer an upstream platform tracker — it is a one-PR repo-side task with the platform precondition satisfied. Worth re-triaging as such rather than leaving it labelled upstream:objectstack / prio:p1; that relabel is the PM's call, and nothing was changed here.

Nothing on this card was changed: still open, labels untouched.

---

Generated by Claude Code

---

Generated by Claude Code

[hotlong]

Transfer sweep (#1156, part 1) — outcome 2: the fix lands in hotcrm. Relabelled and kept here.

The outcome test that was applied

Not "what does the label say" but where would the fix land today? The upstream:objectstack label records what someone believed when this card was filed on 2026-07-28; it is a claim, not a verdict, and on this card it is now wrong.

Verdict: the platform half is fixed, and this card's own closing condition is CRM code

Platform half — fixed. Two independent measurements on @objectstack/* 17.0.0-rc.2 agree that the analytics query path resolves {current_user_id} to a bound SQL parameter, and that an unknown token now fails loudly with a suggestion rather than reaching the WHERE clause as a literal:

runtimeFilter	rows	generated SQL
{is_closed:false} (control)	30	WHERE is_closed = $1
{owner_id:"literal admin id", is_closed:false}	30	WHERE (owner_id = $1 AND is_closed = $2)
{owner_id:"{current_user_id}", is_closed:false}	30	same — token substituted to a bound parameter
{owner:"{current_user}", …}	error	ANALYTICS_QUERY_FAILED: Unresolvable filter placeholder "{current_user}". Did you mean "{current_user_id}"?

Token ≡ literal ≡ control is the correct outcome (all open cases are owner=admin); the rc.0 failure mode was an unresolved literal matching 0 rows. Sources: rc.2 retest · independent re-read.

CRM half — outstanding, and it is this card's stated closing condition. The body's "To close this issue" section names a code change in this repo: restore the personal widget on service_dashboard. src/dashboards/service.dashboard.ts:268-280 still ships the team-wide "Open Cases by Priority", with a source comment still pointing at this issue.

So there is no platform need left to route anywhere. Under the ruling below, that means this is not a transfer.

Confirming #1156's stated expectation, independently

#1156 flagged this card as expected-outcome-2 on the strength of #1151's review, and asked for that to be verified rather than inherited. It holds. The two rc.2 readings above are on-card and mutually independent, and neither recommends closing now — both explicitly withhold the close pending the CRM-side widget restore (「平台半(用户 token 解析)已修;CRM 半(恢复个人 widget)仍待收尾 … 落地后可关」).

Actions taken on this card

• upstream:objectstack — removed. The remaining work is a one-PR change in this repo.
• prio:p1 → prio:p2. P1 was graded when this was a platform blocker making personal dashboard widgets impossible product-wide. What is left is restoring one widget on one dashboard whose precondition is already met — triaged backlog, no near-term schedule.
• bug — kept. It is still a defect from the user's point of view until the widget is back.
• Left open. Nothing about this card is finished.

⚠️ Carried forward for whoever picks this up: the body's restore instruction is stale

The body says to re-add filter: { owner: '{current_user_id}', is_closed: false }. Since #548/#677 the owner column no longer exists and that spelling fails with no such column: owner (measured). Use owner_id. Copying the body verbatim will misfire.

What was NOT done here

No re-measurement on 17.0.0 GA. The platform readings above are rc.2-era and this repo has since moved to GA (#1146 / PR #1147). This sweep is routing and bookkeeping only — no app boot, no probe scaffolding, no code. The widget restore should confirm per-viewer rendering as its own acceptance step.

Authority

• [Transfer sweep] Move all 22 platform-defect cards to the repo the fix lands in, and close them here with a pointer #1156 (transfer sweep), part 1.
• Maintainer ruling, 2026-08-14 — verbatim, untranslated:

hotcrm 席位的原则是用平台的能力做元数据应用的开发，平台的需求应该转给平台

The ruling routes platform needs to the platform. This card no longer carries one, so the companion disposition 「关掉,只留指向镜像的指针」 does not apply: there is nothing to mirror and nothing to point at. Keeping it here is what the ruling requires, not an exception to it.

---

Generated by Claude Code

---

Generated by Claude Code

[hotlong]

Triage (代扫, vacancy clause) → pm:blocked, Blocked-by: objectstack-ai/objectstack#12230 (filed by this seat just now).

Filed 2026-07-28 with bug + prio:p2 and no pm-state, so it has been invisible to every candidate query for four weeks. Vacancy clause: triage actions only.

The premise was re-measured before blocking, and it survives — but its old blocker does not

The card is right that this is upstream, so the only real triage question is what is it waiting on. The answer was not what the paper trail said.

An upstream card for exactly this existed — objectstack#3574, "Dashboard widget filters do not interpolate {current_user_id}" — and it is closed as completed. Taken at face value, this card would have gone back to pm:queue and burned a dispatch on a premise that is still true. It was closed by PR objectstack#3594, "gate unresolvable filter placeholders; freeze the {current_user_id} vocabulary" — an author-time lint, not a substitution in the analytics query path. Real work, and not the thing this card needs.

So I measured the published artefact this repo installs rather than trusting either issue state or release notes. @objectstack/service-analytics@17.1.0, dist/index.js, 226,078 bytes:

target term	hits		control term	hits
current_user	0		filter	173
current_user_id	0		dataset	95
currentUserId	0		measure	167

The controls are stated so the zeros count — a zero result is not a finding until something proves the search reached the code. It does. The gap is intact in the version this repo pins.

Disposition

pm:blocked on the fresh card objectstack#12230, which carries the measurement above and asks for the substitution on its own terms. I filed new rather than reopening #3574 so the lint that did land keeps its closure.

⚠️ The unlock predicate is a read of the published package, not the upstream issue's state. This lane has now been bitten by that gap twice — here, and on #1206, where the blocker closed nine hours after the release that could have carried it. When objectstack#12230 closes, probe @objectstack/service-analytics at whatever version is then pinnable for a non-zero current_user_id count with a control term beside it, and only then return this card to the queue.

prio:p2 retained — the personal use-case is served through list views today, so the app is not broken, only less capable than it reads.

---

Generated by Claude Code