You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e607df7
Browse filesBrowse the repository at this point in the historyBrowse files
fix(core): date macros in a filter resolve on the workspace timezone's day, so an authored view's `{today}` and a reader's panel `{today}` name the same day
7
+
8
+
Clause-②: no
9
+
Metadata-protocol: none
10
+
11
+
-**Before.**`resolveDateMacros` read the browser's clock. A list view's authored filter is resolved in the browser before it is sent, while a reader's filter-panel rule is sent with the macro unresolved and the server resolves it in the workspace `localization.timezone`. When the browser and the workspace were on different days, `close_date between ['{today}', '{today}']` authored on a view asked for one day and the same rule from the panel asked for the other; both on one list sent both days and matched nothing.
12
+
-**Now.** The calendar tokens (`today`, `yesterday`, `tomorrow`, the week, month, quarter and year bounds, `N_days` / `N_weeks` / `N_months` / `N_years`) resolve on the day of the display zone `LocalizationProvider` declares from the served `localization.timezone`, the zone the server uses. The instant tokens (`now`, `N_minutes`, `N_hours`) stay on the real instant. With no workspace zone known, the browser's clock decides, as before. The list's authored filter is resolved again when the workspace zone arrives after the first render.
13
+
- No signature changes: `resolveDateMacros(filter, now?)` keeps its parameters and reads the zone the date faces already read. Every surface that resolves macros through it (lists, kanban, calendar, gantt, timeline, map, tree, gallery, related lists, grids, dashboards, charts, compare-to, calendar `initialDate`) now names the workspace day too.
fix(spec): `os migrate meta --stored` lists a stored dashboard that declares one global filter key twice
6
+
7
+
Clause-②: no
8
+
Metadata-protocol: none
9
+
10
+
-**Before.**`DashboardSchema` refuses a dashboard whose `globalFilters` repeats a filter key (its `name`, or its `field` when it has no `name`), and the dashboard save door answers 422 `INVALID_METADATA`. A dashboard already stored in that shape still loads with `_diagnostics` reading `valid: false`, but the v18 stored-row preview had no detector for it, so `os migrate meta --stored` named no such row before the upgrade.
11
+
-**Now.** The preview lists each stored dashboard that repeats a key, under the TODO id `ui-dashboard-global-filter-duplicate-name-refused` (the refusal's upgrade guide entry), at the second declaration's `name` (or `field`) — the site the parse refuses — naming the key and every index. The detector calls the refinement's own predicate, so a row is listed exactly when the parse refuses it. Nothing rewrites it: which definition keeps the key only the author knows.
12
+
-**Not changed.** What any door accepts or refuses. Distinct keys, and distinct names over one `field`, are not listed.
0 commit comments