docs: say the parent default is set in the builder, not on any dashboard

[mngr]

Applies the review comment on #11685 that I merged past — my mistake, so this lands as a follow-up rather than an edit to that PR.

The finding was right. #11685 opened the Default option paragraph with:

The option a parent control opens on is the one you last picked in the control itself on the dashboard …

which is ambiguous about which dashboard. A viewer changing a parent control on a published dashboard does not change the saved default — only a pick in the builder does. The following sentence said so, but the lead sentence is the one people skim, and on its own it reads as "whatever was last selected wins."

This uses the reviewer's suggested wording, which mirrors the phrasing the filter section already uses one screen up ("configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget") and collapses two sentences into one:

A parent control's default is set the same way a filter's static default is — by interacting with the control in the dashboard builder. The option you select is saved on the widget and applied to every viewer when the dashboard loads; there's no Default value field in the parent's settings.

Product change: cubedevinc/cubejs-enterprise#14501 (CUB-4201), merged.

[mintlify]

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

Project	Status	Preview	Updated (UTC)
cubed3	🟢 Ready	View Preview	Aug 28, 2026, 7:19 PM

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

[claude]

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

---

Review complete — no blocking issues (0 high, 0 medium, 1 low)

The one-line rewording is accurate, consistent with the filter section, and reads better. LGTM.

Details

• Gather context (diff vs origin/master, full controls.mdx)
• Check wording against the filter and time-granularity sections
• Check for stale/duplicate Claude review threads (none exist on this PR)
• Post review

What changed

docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx:150 — the Default option lead sentence.

Assessment

Correctness of the fix. The original lead ("the one you last picked in the control itself on the dashboard") did read as if a viewer's pick on a published dashboard could set the default, which contradicts both the following sentence and the "Published dashboards only" bullet at line 192-193. The new phrasing removes the ambiguity by naming the builder up front.

Consistency. It now mirrors the static-default sentence at line 41 ("configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget and applied to every viewer when the dashboard loads"), which is the right precedent to follow — a reader who skimmed the filter section one screen up will recognize the shape.

Unmentioned improvement worth calling out. The old sentence also compared the parent default to "a time granularity switcher's default", which was wrong: per the Default granularity section (line 94-96), the switcher does have a configurable default in its settings, so it isn't set by interaction at all. Dropping that half of the comparison fixes a second, unrelated inaccuracy. Good that the narrower comparison to the filter's static default is the only one left.

Downstream paragraphs still read correctly. Line 152 ("Picking in the builder also applies that option's values to the children…") and line 154 (never picking / deleting the default option) follow on cleanly from the new lead — no orphaned "the same way…" reference left behind.

Low — bolding a field that doesn't exist

controls.mdx:150 — there's no **Default value** field in the parent's settings. Bold is used throughout this page for real UI labels (Children, Reset to default, Visibility, Configure Parent). Bolding Default value for a field that explicitly does not exist is a small inconsistency in that convention, and a reader skimming bold text could come away thinking the field is there. Unbolding it, or phrasing it as "there's no default field in the parent's settings", would sidestep this. Purely stylistic — not worth blocking on, and the sentence is unambiguous when read in full.

Not applicable

Security, performance, and test-coverage checks are moot for a prose-only change to a single .mdx line. No docs.json navigation update is needed (no new page). Per docs-mintlify/CLAUDE.md, the edit is correctly in /docs-mintlify rather than the deprecated /docs, and the commit follows the docs: conventional-commit prefix.

· branch [`docs/parent-default-disambiguate-builder`](https://github.com/cube-js/cube/tree/docs/parent-default-disambiguate-builder)

[claude]

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

---

Review complete — 0 high, 1 medium, 0 low

The reworded lead is accurate and consistent with the filter section, and the follow-up commit resolved the earlier bolding nit. One new issue appeared from master moving underneath this branch.

Details

• Gather context (diff of both commits, current controls.mdx, origin/master version)
• Re-check wording against the filter static-default section
• Check existing review threads (none on this PR)
• Post review

What changed since the last review

393a398 unbolded Default value and rephrased to "there's no default field in the parent's settings" — that addresses the low finding from the previous pass. Bold is now reserved for real UI labels throughout the page, as it should be.

Medium — the new sentence contradicts a section that landed on master after this branch

docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx:150

This branch forked before #11689, which added a User attribute default subsection directly beneath Default option on master:

To give each viewer their own, turn on User attribute default in the parent control's settings and pick a user attribute.

So on master there is a default-related field in the parent's settings. Once this merges, line 150's absolute claim —

…there's no default field in the parent's settings.

— sits one paragraph above a subsection that tells the reader to go find exactly such a field. A reader skimming top-down hits the denial first and may skip the subsection entirely.

The filter section one screen up already models the fix: it splits Static default from User attribute default and scopes its "configured by interacting with the filter" sentence to the static case only (line 41). Mirroring that is a one-word change:

…applied to every viewer when the dashboard loads; there's no static default field in the parent's settings.

Or, if you'd rather point forward explicitly: …there's no field for it in the parent's settings — see User attribute default below for per-viewer defaults.

Note this only bites after a merge/rebase onto current master — the branch as it stands is internally consistent, so it's a merge-order artifact rather than a defect in the diff itself. Worth fixing here rather than leaving for a third follow-up.

Fix this →

Still correct from the previous pass

• Dropping the old comparison to "a time granularity switcher's default" remains the right call — per Default granularity (line 94-96) the switcher does have a configurable default, so that half of the comparison was inaccurate.
• Downstream paragraphs (lines 152, 154) follow on cleanly from the new lead; no orphaned back-reference.
• Edit is correctly in /docs-mintlify rather than the deprecated /docs, and both commits use the docs: prefix per CLAUDE.md.

Not applicable

Security, performance, and test-coverage checks are moot for a prose-only change to one .mdx line. No docs.json update needed — no new page.

· branch [`docs/parent-default-disambiguate-builder`](https://github.com/cube-js/cube/tree/docs/parent-default-disambiguate-builder)

[claude]

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

---

Review complete — 0 high, 0 medium, 0 low

The new commit resolves the medium finding from the last pass; the page is now internally consistent against current master. LGTM.

Details

• Gather context (commits, diff vs origin/master, current controls.mdx)
• Verify the previous medium finding is addressed
• Re-check wording against the filter static-default and user-attribute sections
• Check existing review threads (none on this PR)
• Post review

What changed since the last review

1f42189 scoped the denial to the static case:

…applied to every viewer when the dashboard loads; there's no static default field in the parent's settings.

That is exactly the fix the previous pass asked for. controls.mdx:150 no longer contradicts the User attribute default subsection at line 156, which does point the reader at a default-related toggle in the parent's settings. Read top-down the two now compose: no static field, but a per-viewer one — the same static/attribute split the filter section establishes at lines 40-41.

Verified against the rest of the page

• Mirrors the filter precedent. Line 41 ("Static defaults are configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget and applied to every viewer when the dashboard loads") and line 150 now use the same shape and the same qualifier. A reader who skimmed one screen up recognizes the pattern.
• Cross-reference holds. Line 41's "Parent controls support this too" resolves to the section this PR edits, and that section carries the user-attribute subsection — the link isn't left pointing at a contradiction.
• The dropped granularity comparison stays dropped. The original lead likened the parent default to "a time granularity switcher's default", which was wrong — per Default granularity (line 96) the switcher has a configurable default in its settings. Narrowing to the filter's static default alone is still the right call.
• Downstream paragraphs unaffected. Lines 152 and 154 follow on cleanly from the new lead; no orphaned back-reference, and the fallback sentence at line 182 ("falls back to the default option you picked") is consistent with the lead's "the option you select is saved on the widget".
• Bold convention. 9da5cf1 already unbolded the non-existent field name; bold on this page is now reserved for real UI labels (Children, Configure Parent, User attribute default, Disabled).

Not applicable

Security, performance, and test-coverage checks are moot for a prose-only change to a single .mdx line. No docs.json navigation update needed — no new page. Per CLAUDE.md, the edit is correctly in /docs-mintlify rather than the deprecated /docs, and all three commits use the docs: conventional-commit prefix.

· branch [`docs/parent-default-disambiguate-builder`](https://github.com/cube-js/cube/tree/docs/parent-default-disambiguate-builder)