docs(dashboards): say that a chart opened in the workbook keeps the dashboard's filters

[mngr]

Documents the behaviour shipped in cubedevinc/cubejs-enterprise#14628 (CUB-4102).

"Edit in Workbook" now carries the dashboard's filters into the report session: the report opens on the same slice the chart was showing instead of re-running unfiltered, and the carried filters are shown as a read-only From dashboard row that is never saved into the report.

The docs had no entry for "Edit in Workbook" at all, so this adds it under Updating charts — the action, and then what happens to the filters, including the two things a reader can get wrong: that these are not report filters (publishing will not pin them onto the chart) and that changing what viewers can filter by means editing the control, not the report.

[claude]

Claude finished @mngr's task in 1m 7s —— View job

---

Docs review — no blockers, 2 low-severity clarity notes

Correct place, correct site (/docs-mintlify), links resolve, house style respected. Two wording issues posted inline; neither blocks merge.

Review details

• Gather context (diff, full page, sibling widget pages)
• Check repo docs conventions (docs-mintlify/CLAUDE.md)
• Verify link refs and terminology
• Post findings

What's good

• Lands in docs-mintlify (active site), not the deprecated /docs.
• Extends an existing page under an existing H2 rather than creating a new page — exactly the "surgical edit" default in docs-mintlify/CLAUDE.md.
• [ref-controls] is already defined at charts.mdx:42; no new link refs needed, no docs.json change required.
• Terminology matches the product taxonomy (Widget → Controls → Filter), and "a chart's settings menu" (line 24) matches existing usage at controls.mdx:318.
• The two reader traps called out in the PR description — that carried filters aren't report filters, and that changing viewer-facing filtering means editing the control — are both stated plainly and in the right order.

Findings

#	Location	Severity	Issue
1	charts.mdx:31	low	"they are read-only" contradicts the next clause telling the reader to remove one; **×** names a glyph rather than an affordance; bullet punctuation diverges from the page's sentence style. inline
2	charts.mdx:28	low	Link text "filters" points at the all-controls page — leaves open whether time granularity / field switcher selections also carry into the workbook. inline

Security / performance / testing sections of the review checklist don't apply — this is a prose-only change with no code, no config, and no navigation edit.

Not verified: I didn't run the Mintlify dev server, so rendering is unchecked. The change adds no new components or link refs, so the risk of a render break is essentially nil.

· branch [`docs/dashboard-filters-into-workbook-cub-4102`](https://github.com/cube-js/cube/tree/docs/dashboard-filters-into-workbook-cub-4102)

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
cubed3	🟢 Ready	View Preview	Sep 1, 2026, 6:43 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[claude]

Claude finished @mngr's task in 1m 31s —— View job

---

Docs re-review — both prior notes addressed, 2 new low-severity clarity notes

0f8d1dd resolves both threads from the last pass and adds real substance (dedup/AND semantics, scope of what carries). No blockers.

Review details

• Read the new commit (0f8d1dd) and the full page
• List existing review threads
• Resolve my own stale threads
• Post findings on the current text

Prior threads — both resolved

Prior note	Status in 0f8d1dd
"they are read-only" contradicted the next clause; **×** named a glyph not an affordance	Fixed — now "they cannot be edited here" plus "Clear filter on the chip" (resolved)
"filters" linked to the all-controls page; unclear whether granularity/field switchers ride along	Fixed — line 38 states it outright: "Only filters are carried… does not follow into the workbook" (resolved)

What the new commit adds well

• Line 36 answers the question the first draft left open — what happens when the report already filters the same field. "Both filters apply… so the numbers match the chart you came from" gives the reader the why, not just the rule, and the dedup carve-out that follows is the non-obvious half.
• Line 38 bounds the feature. Scope statements like this are what stop a support ticket.
• Still a surgical edit to an existing page under an existing H2, on the active site — matches docs-mintlify/CLAUDE.md.

New findings

#	Location	Severity	Issue
1	charts.mdx:30	low	Color is now the only cue distinguishing a carried filter; the textual "From dashboard" marker from commit 1 was dropped. Only color-as-identifier in the whole explore-analyze tree. inline
2	charts.mdx:33	low	Bullet conflates "you can't edit this here" with "change what viewers can filter by" — two different reader needs, first one unanswered. Plus ; terminators on now-multi-sentence bullets. inline

Adjacent, out of scope: line 16 still lists dashboard controls as "filters and time granularity switchers", omitting the field switcher documented in #11710 — worth a separate one-word fix, not this PR's job.

Security / performance / testing don't apply — prose-only, no code, no docs.json change, no new link refs.

Not verified: whether the chips actually render violet and whether they carry a label, and Mintlify rendering (dev server not run). No new components, so render risk is nil.

· branch [`docs/dashboard-filters-into-workbook-cub-4102`](https://github.com/cube-js/cube/tree/docs/dashboard-filters-into-workbook-cub-4102)

[claude]

Claude finished @mngr's task in 53s —— View job

---

Docs re-review — both prior notes fixed in 1edd5ca; no blockers, 2 very low nits (summary only, no new inline comments)

Review details

• Read the new commit (1edd5ca) and the full page
• List existing review threads
• Resolve my own stale threads
• Assess the current text

Prior threads — both resolved

Prior note	Status in 1edd5ca
Color ("in violet") was the only cue distinguishing a carried filter	Fixed — line 30 now names the durable cue, "Hovering one says From dashboard", and keeps "tinted violet to set them apart" as the secondary at-a-glance signal (resolved)
One bullet conflated "can I change this?" with "what can viewers filter by?"; ; terminators on multi-sentence bullets	Fixed — line 33 now answers the workbook user ("add your own filter on the same field, or change the dashboard's control and reopen"), and the viewer-facing guidance stands alone at line 36. All bullets end in full stops (resolved)

What reads well now

• Line 33's two escape hatches are consistent with line 38's dedup/AND rule — a reader who adds their own filter on the same field can predict what happens, because the page already told them both filters apply.
• The section answers, in order: what the action does (24), what carries (28), how to recognize it (30), what it isn't (32–34), who to talk to about viewer-facing filtering (36), what happens on overlap (38), what doesn't carry (40). No gap I can find.
• Still a surgical edit to an existing page under an existing H2 on the active site, no docs.json change, no new link refs — matches docs-mintlify/CLAUDE.md.

Nits (not worth another inline round)

1. charts.mdx:16 — the page's own controls list still reads "filters and time granularity switchers", omitting the field switcher. This PR's line 40 now names the field switcher explicitly, so the omission at line 16 is an in-page inconsistency the PR surfaces. One-word fix, and arguably a separate PR's job as I noted last round.
2. charts.mdx:34 — the lead-in "they are not the report's:" governs bullets 1 and 2 ("they apply…", "their values…") but not bullet 3, which starts with the UI affordance. Reads fine in practice; flagging only for completeness.

Security / performance / testing don't apply — prose-only change, no code, no config.

Not verified: whether the chips actually render violet and carry a "From dashboard" tooltip (that's a product claim I can only take from the linked enterprise PR), and Mintlify rendering — dev server not run. No new components or refs, so render risk is nil.

· branch [`docs/dashboard-filters-into-workbook-cub-4102`](https://github.com/cube-js/cube/tree/docs/dashboard-filters-into-workbook-cub-4102)

[claude]

Claude finished @mngr's task in 1m 10s —— View job

---

Docs re-review of 3aa19a0 — no blockers; 2 low (1 factual knock-on, 1 wording)

Review details

• Read the new commit (3aa19a0) and the full page
• List existing review threads (all 4 prior threads already resolved)
• Cross-check the controls-list edit against controls.mdx
• Post findings

Prior rounds

All four of my earlier threads are resolved and outdated; nothing to re-affirm. 3aa19a0 picks up both nits from the last summary — the field switcher is now named at line 16, and bullet 3 no longer opens on the UI affordance.

Findings

#	Location	Severity	Issue
1	charts.mdx:16	low	Adding field switchers to the list makes the next sentence wrong: "its value is applied to every chart whose query references the targeted dimension". Filters and granularity switchers "always target a dimension", but a field switcher targets a dimension or a measure and scopes on whichever it's set to (controls.mdx:299, 337-338). "member" covers both. inline
2	charts.mdx:34	low	"they can be dropped, but not kept" reads two ways — the removal doesn't stick (what the bullet then says), or you can't save one into the report (what bullet 1 already says). The rest of the bullet already earns the lead-in. inline

Finding 1 is the more interesting one: it's a knock-on the commit created rather than an error in what it wrote. Widening a list is cheap; the sentence that generalizes over that list is where the widening has to be paid for.

Checked and fine

• "filters, time granularity switchers and field switchers" at line 16 matches controls.mdx:297 verbatim, including the absent serial comma — so the missing Oxford comma is sibling-page consistency, not a slip. Nothing to raise.
• Terminology matches the taxonomy in docs-mintlify/CLAUDE.md (Widget → Controls → Filter / Time granularity / Field switcher / Parent). Parent controls are correctly absent from line 16's list, since a parent never applies to a chart query directly (controls.mdx:165).
• [ref-controls] still resolves (charts.mdx:49); no new refs, no docs.json change needed.
• Still a surgical edit to an existing page under an existing H2 on the active site — matches docs-mintlify/CLAUDE.md.

Security / performance / testing / comment-hygiene sections of the checklist don't apply — prose-only change, no code, no config.

Not verified: the product claims themselves (violet tint, From dashboard on hover, Clear filter on the chip) — I can only take those from the linked enterprise PR. Mintlify rendering unchecked (dev server not run); no new components or refs, so render risk is nil.

· branch [`docs/dashboard-filters-into-workbook-cub-4102`](https://github.com/cube-js/cube/tree/docs/dashboard-filters-into-workbook-cub-4102)

[claude]

Adding field switchers to this list makes the next sentence inaccurate. "its value is applied to every chart whose query references the targeted dimension" was true when the list was filters + time granularity switchers, both of which "always target a dimension" (controls.mdx:299). A field switcher targets a dimension or a measure depending on its Field Type, and scopes on whichever it is set to (controls.mdx:299, and the auto-scoping table at controls.mdx:337-338).

So a reader with a measure-mode field switcher is told, on this page, that scoping follows a dimension reference. "member" is the term controls.mdx uses for the general case and covers both.

Suggested change

	Charts respect the [controls][ref-controls] placed on the same dashboard — filters, time granularity switchers and field switchers. A single control can drive multiple charts at once: its value is applied to every chart whose query references the targeted dimension.
	Charts respect the [controls][ref-controls] placed on the same dashboard — filters, time granularity switchers and field switchers. A single control can drive multiple charts at once: its value is applied to every chart whose query references the targeted member.

Fix this →

[claude]

"they can be dropped, but not kept" is ambiguous in a way the previous wording wasn't. Two readings, both plausible under the lead-in "they are not the report's":

1. you can remove one, but you can't make the removal stick (which is what the rest of the bullet actually says — reopening brings it back);
2. you can remove one, but you can't keep/save one into the report (which is bullet 1's point, already made).

The clause is trying to earn its place under the lead-in, but the rest of the bullet already does that work: a filter whose removal survives only the session is self-evidently not the report's. Dropping the prefix loses nothing.

Suggested change

	- they can be dropped, but not kept: **Clear filter** on the chip removes it for the rest of the session and the report re-runs without it. Reopening the chart from the dashboard brings the current values back.
	- **Clear filter** on the chip removes it for the rest of the session and the report re-runs without it — but the removal isn't saved either. Reopening the chart from the dashboard brings the current values back.