Skip to content

docs(dashboards): parent-control reset re-resolves a child's user-attribute default (CUB-4464) - #11799

Merged
mngr merged 2 commits into
masterfrom
mngr/cub-4464-parent-reset-attribute-docs
Sep 9, 2026
Merged

docs(dashboards): parent-control reset re-resolves a child's user-attribute default (CUB-4464)#11799
mngr merged 2 commits into
masterfrom
mngr/cub-4464-parent-reset-attribute-docs

Conversation

@mngr

@mngr mngr commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Pairs with the product fix in cubedevinc/cubejs-enterprise#14796 (CUB-4464).

Previously a parent control's Reset to default mapping sent a child to its static default even when the child took its default from a user attribute — so a per-viewer control was reset to a state that viewer never actually opens the board on. The behaviour now returns the child to the value it opens on for that viewer: the attribute value when one resolves, otherwise the static default (unchanged for controls with no attribute).

Updates the three places in controls.mdx that stated the old behaviour:

  • Time granularity switcher × parent (the "Reset to default … rather than re-resolving the attribute" sentence).
  • Field switcher × parent (same).
  • The Children mapping table's Reset to default row.

No other behaviour changed.

@mngr
mngr requested a review from keydunov as a code owner September 8, 2026 16:47
@mintlify

mintlify Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

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

Project Status Preview Updated
cubed3 🟢 Ready View Preview Sep 8, 2026, 4:48 PM

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

@github-actions github-actions Bot added the pr:community Contribution from Cube.js community members. label Sep 8, 2026
@claude

claude Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

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


Docs review — looks good; 2 low-severity nits posted inline

Details
  • Gather context (diff vs origin/master, full controls.mdx)
  • Classify request → PR review
  • Verify the three edits are consistent with each other and the rest of the page
  • Check anchors and cross-references
  • Check for other places stating the old behaviour
  • Post feedback

Verdict

The change is accurate to what the PR body describes and the three edits are the right three places. All anchors used resolve: #default-granularity (L95), #field-switcher-default-option (L154, explicit), #user-attribute-default (L74 area, filter section), #children, #allowed-granularities. Nothing else in docs-mintlify mentions "Reset to default", so the sweep is complete for this file's phrasing.

I couldn't verify the behaviour against the product fix — cubedevinc/cubejs-enterprise#14796 is a private repo not reachable from here — so this review is on internal consistency and wording only.

Findings

# Where Severity Issue
1 controls.mdx:221 low The generic [user attribute](#user-attribute-default) link points at the filter section, but the row now covers all three child types. Also, the filter's own section (L74, "only seeds the filter's initial value") is now the one child type whose parent-reset behaviour is stated only in this table — the granularity and field-switcher sections each say it in prose.
2 controls.mdx:132 low "leaves it untouched when neither is set" — an attribute can be set and still not resolve (or resolve outside the allowed granularities, L126). "neither resolves" matches the "when one resolves" clause immediately before it. Suggestion posted inline.

Notes, not findings

  • The two prose edits are deliberately asymmetric in how they qualify the attribute: granularity says "when one resolves", field switcher says "when the switcher still offers it". Both are correct for their control — the field switcher's constraint is membership in Alternatives, the granularity's is the allowed list — so the asymmetry reads as precision rather than inconsistency.
  • The table row got noticeably denser (one sentence carrying the attribute case plus three static-default cases). It's still parseable and splitting it would cost more than it buys, so I'd leave it.
  • Parent controls can't be children, so the parent's own #parent-user-attribute-default section correctly needed no change.
· branch `mngr/cub-4464-parent-reset-attribute-docs`

Comment thread docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx Outdated
Comment thread docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx Outdated
@claude

claude Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

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


Re-review after acf15e8 — both prior nits addressed; 1 low-severity leftover

Details
  • Gather context (diff vs origin/master, full controls.mdx)
  • Check whether my two prior threads are addressed
  • Verify the new anchors resolve
  • Sweep for other places stating the old behaviour
  • Post feedback

Verdict

acf15e8 addresses both threads from the last round:

  1. Per-type user-attribute anchors (L221) — the table row now names all three: #user-attribute-default (filter, L44), #time-granularity-user-attribute-default (explicit anchor, L99), #field-switcher-user-attribute-default (explicit anchor, L170). All three resolve. Naming them inline (a filter's, a time granularity switcher's, or a field switcher's) also fixes the ambiguity of the bare "user attribute" link. #default-granularity (L95) and #field-switcher-default-option (L154) still resolve too.
  2. "when neither resolves" (L132) — applied verbatim; it now matches the "when one resolves" clause it pairs with, and covers an attribute that's configured but resolves outside allowed granularities.

The colon before the static-default list (otherwise it's the child's own static default: no filtering…) is a small readability win over the previous em-dash — the row is dense but parses.

Sweep is clean: the only three occurrences of "Reset to default" prose in docs-mintlify are the three lines this PR touches, and nothing else says "rather than re-resolving".

Remaining (low, unchanged from last round — second half of thread 1)

controls.mdx:73 still reads:

The user attribute default only seeds the filter's initial value.

With this change, a parent's Reset to default re-resolves that attribute, so it's no longer only the initial value — the filter section is now the one child type whose parent-reset behaviour a reader has to infer from the L221 table, and "only … initial" mildly contradicts it. The granularity (L132) and field-switcher (L176) sections each state it in prose. A clause would close it, e.g.:

…seeds the filter's initial value, and is re-resolved when a parent control option set to Reset to default returns the filter to its default.

I couldn't post this inline — L73 isn't in any diff hunk. Not blocking; the table is correct as written. Fix this →

Notes

  • Both of my earlier threads are already resolved and outdated; nothing of mine left to resolve.
  • Still can't verify against the product fix — cubedevinc/cubejs-enterprise#14796 is a private repo not reachable from here. This review covers internal consistency and wording only.
· branch [`mngr/cub-4464-parent-reset-attribute-docs`](https://github.com/cube-js/cube/tree/mngr/cub-4464-parent-reset-attribute-docs)

@mngr
mngr merged commit e6529d5 into master Sep 9, 2026
21 checks passed
@mngr
mngr deleted the mngr/cub-4464-parent-reset-attribute-docs branch September 9, 2026 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:community Contribution from Cube.js community members.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant