fix(dashboards): drop the Service dashboard date range — datetime filters match nothing (#460)

[yinlianghui]

Description

Note: the first push on this branch widened the default preset to last_90_days. Running the app disproved that diagnosis — see below. The current commits remove the date range instead. The earlier description is superseded.

service_dashboard opened with every KPI at 0 and every chart reporting no rows, with 38 cases in the system. The preset was never the cause, and no preset fixes it.

crm_case.created_date is a Field.datetime(). On the SQLite path, driver-sql 16.1.0 coerces datetime filter comparands to epoch-millisecond INTEGERs while writes store ISO TEXT. SQLite orders every INTEGER before every TEXT, so on a datetime column:

created_date >= <int>   is TRUE  for every row   (the window has no floor)
created_date <= <int>   is FALSE for every row   (the window matches nothing)

The runtime ANDs the dashboard range into every widget query, so the $lte half zeroed the whole dashboard.

Measured, not inferred

Against the running 16.1.0 console (pnpm demo:reset && pnpm dev, logged in, same case_metrics dataset the widgets use, varying only the created_date filter):

filter	rows
none	38
$gte only (2026-05-01)	38
$lte only (2026-07-30)	0
$gte + $lte (the dashboard's own window)	0
$gte + $lte, full ISO with end-of-day	0

Confirmed at the storage layer: SELECT typeof(created_date) is text for all 38 rows, and binding the same bounds as strings in raw SQL returns 38 — so the window is right and the binding is not.

Why the other three dashboards are fine: they window close_date, a Field.date(), which stays TEXT YYYY-MM-DD on both sides of the comparison. That is why Service was the outlier — not the preset choice.

Upstream status

This is a platform defect, already reported:

• [17.0.0-rc.0] SQLite datetime window filters return empty: filter comparands coerced to epoch-ms while writes store ISO TEXT objectstack#3912 — closed as completed 2026-07-29. Same mechanism, same measurements, filed while upgrading this app 16.1.0 → 17.0.0-rc.0. Fix is in the 17.0 train; HotCRM is pinned to 16.1.0, so the defect is live here. No new upstream issue was filed — this one covers it.
• dashboard 的日期区间上界打在 datetime 列上丢失当天数据 —— 默认配置即命中 objectstack#3777 — open, bug/priority:p1. A separate datetime bug: a bare YYYY-MM-DD $lte upper bound on a datetime column drops every record created after 00:00 that day — silently, by an amount that grows through the day.

The second one matters for the restore condition: upgrading the platform alone does not make it safe to window a datetime field. Both fixes must land first, which is what the code comment and the CI guard now encode.

On this side, #520 already tracks the same root cause from the 17.0-rc upgrade angle — #460 is the 16.1.0 view of one dashboard, #520 is the platform-wide impact and the upgrade path. This PR resolves the former and leaves the latter open; measurements are cross-posted there.

What this PR does

Removes the dateRange block rather than widening it. Verified in the browser: 30 open / 7 critical / 45.0h avg resolution / 3 SLA breaches, every chart and the table populated.

The cost is visible and intentional: this dashboard has no date picker for now. The block is left commented out at the exact spot to restore, with both upstream issue numbers as the precondition. A picker that zeroes every widget is strictly worse than no picker.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Code refactoring
• Performance improvement
• CI/CD update

Related Issues

Fixes #460
Refs #520 (same root cause, platform-wide impact and 17.0 upgrade path — stays open)
Refs objectstack-ai/objectstack#3912 (fixed upstream, 17.0 train) · objectstack-ai/objectstack#3777 (open — blocks restoring the range)

Changes Made

• src/dashboards/service.dashboard.ts — remove the dateRange block; document the root cause, the measurements, both upstream issues, and the restore precondition in place.
• src/dashboards/service.dashboard.ts — document that the daily_case_volume widget's $gte: '{30_days_ago}' floor is inert for the same reason (a $gte on a datetime is true for every row), so that chart currently plots every case, not the last 30 days. Indistinguishable today because the seed spans exactly 30 days; it starts working when the driver is fixed. Flagged rather than papered over — the title's claim isn't enforced yet.
• test/metadata-references.test.ts — replaces the window-arithmetic guard from the first push, which could not detect this class of defect at all. The new guard fails if any dashboard windows a datetime field, and a second test checks the range field actually exists on the objects its widgets aggregate.
• .changeset/service-dashboard-default-date-range.md — patch changeset.

Note on the issue's other suggestion (seed recent cases): already landed independently in #481 — the case seed dates every record relative to boot, daysAgo(1..30). It didn't help, because the $lte bound matches nothing regardless of how recent the rows are.

Not touched, deliberately: the four hardcoded trend blocks in this file are fabricated figures, but they belong to the review pass in #500 (which turns out to cover only the executive dashboard's four of sixteen — noted there).

Testing

• Unit tests pass (pnpm test — 8 files, 91 tests)
• Linting passes (pnpm lint — 2 warnings, both pre-existing and unrelated: crm_quote_line_item naming/relationship suggestions)
• Build succeeds (pnpm build, plus pnpm validate and pnpm typecheck clean)
• Manual testing completed — pnpm demo:reset && pnpm dev, logged in as the seeded dev admin, opened the Customer Service dashboard in Chromium. Zeros before, real numbers after; captured the analytics request/response pairs and the executed SQL for the table above.
• New tests added (if applicable)

The new guard was verified in both directions: it fails with the exact message service_dashboard: dateRange windows crm_case.created_date, a datetime field — the $lte bound matches no rows, so every widget renders empty when the removed block is restored, and passes without it.

Screenshots

Customer Service dashboard after the fix — KPI tiles at 30 / 7 / 45.0h / 3, donut, pie and bar charts all populated. (Before: every tile 0, every chart "No rows".)

Checklist

• I have added a changeset (pnpm changeset) — required on every PR, or the skip-changeset label is applied
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation — no doc mentions this dashboard's date range; docs-drift passes
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Additional Notes

Two things a reviewer may want to weigh in on:

1. No picker vs. a broken picker. I chose removal. The alternatives were keeping dateRange with filterBindings: { dateRange: false } on every widget (a visible control that does nothing — the ADR-0078 shape this repo keeps removing), or adding a date-typed mirror of created_date to crm_case (a schema change to work around a driver bug, needing hook and seed upkeep).
2. Scope. This stops HotCRM from tripping the defect; it does not fix it. Every other datetime filter in the app has the same problem — $gte silently matches everything, $lte silently matches nothing — so more surfaces are likely affected. That sweep belongs to [17.0-rc][疑似平台] datetime 字段的时间窗过滤返回空集（客服仪表盘全空） #520; #3912's own report notes the platform's created_at / updated_at audit columns are equally affected, and those are everywhere.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Jul 30, 2026 2:51am