[pull] master from cube-js:master - #698
Merged
Merged
Conversation
…UB-1858) (#11688) * docs: the AI "what changed" summary in scheduled-refresh notifications Documents the opt-in "Include AI summary" toggle on a scheduled refresh's notification (CUB-1858), shipped in cubedevinc/cubejs-enterprise#14421. Covers the parts a reader cannot infer from the toggle: that the note compares against the PREVIOUS notification rather than periods inside the data (so a daily send does not repeat itself), that it falls back to week/month windows on a first send and says so rather than inventing a comparison, that each recipient's note is generated under their own data access, and that a failed generation still delivers the notification. Also distinguishes it from the existing AI summary WIDGET, which now shares the name: that one lives on the dashboard, takes a prompt you write, and is cached for all viewers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: address review — add the run phase the feature actually adds Four review findings, all fair; the fourth corrects a claim in my own PR description. - The `Run phases` list in scheduled-refreshes.mdx IS a second list to keep in sync, and CUB-1858 adds a phase to it. The sidebar now shows "Generating AI summary" between the screenshot and the send, so the enumerated list was stale the moment this shipped. Verified the wording against the en-US string the UI renders rather than paraphrasing it. - Declared the code fence as `text`, per docs-mintlify/CLAUDE.md. - "since the last one" -> "since the previous notification": "one" could bind to `refresh`, the noun in the preceding sentence, and the distinction between the two is the whole point of the section. - Moved the stranded `[ref-download]` definition into the reference block at the bottom where every other ref lives, instead of leaving it floating between two sections. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: collapse the blank line left by moving [ref-download] Removing the link definition took the line but not the blank around it, leaving a double blank before the new heading. Checked the whole file for other double-blank runs while here: none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Gleb <gleb@unknownd2d4c7120595.localdomain> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…ard (#11690) * docs: say the parent default is set in the BUILDER, not on any dashboard Follow-up to #11685, applying a review comment that landed on it before it was merged. "the one you last picked in the control itself on the dashboard" 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 — and the lead sentence is the one people skim. Mirror the phrasing the filter section already uses ("configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget"), which also collapses the two sentences into one and keeps the paragraph its original length. * docs: don't bold a parent-settings field that doesn't exist Review note on this PR: bold is used throughout controls.mdx for real UI labels (**Children**, **Reset to default**, **Visibility**), so bolding **Default value** for a field that explicitly is NOT there works against the convention — a reader skimming the bold text could come away thinking it exists. * docs: scope the parent default denial to the STATIC default #11689 landed on master while this branch was open, adding a **User attribute default** subsection directly beneath **Default option** — so there IS now a default-related field in the parent control's settings, and a flat "there's no default field" sits one paragraph above a subsection telling readers to go find exactly such a field. Scope it to the static default, the same split the filter section one screen up already makes between **Static default** and **User attribute default**.
#11693) * docs: close the gaps review found in the parent user-attribute default Follow-up to #11689, which I merged on green checks before reading its review comments — my mistake; a passing review job is not the same as no findings. - A rename is safe for the child mappings and NOT for the attribute match, which is by label. Moving a label away from the attribute's values silently stops it resolving, with no error, so that now has a <Warning> instead of borrowing the reassurance from the Options section. - The setup step offered two entry points; the switch lives in the Configure Parent editor, below the Options/Children tabs beside Visibility. Names the one path and where to look. - Gives the heading an explicit `{#parent-user-attribute-default}` id, so the cross-link from the filter's section lands on the subject rather than a section above it, and stops depending on Mintlify's duplicate suffix. - Closes the case the paragraph exists for: a recipient who has a shared link AND their own attribute. A parent has no URL parameter of its own, so the link carries its children's values and the dropdown follows them. * docs: only a picked option travels in the link, and qualify the rename all-clear at its source Two more from review of this PR: - The URL sentence contradicted the Sharing section further down. Checked it against the implementation rather than picking a side: seeded values carry `asDefault`, so filters are subtracted from the serialized set and time grains are never marked shareable. An untouched, attribute-resolved parent therefore puts NOTHING in the link and the recipient still opens on their own attribute — my sentence claimed the opposite for the most common case. Now scoped to the case where the sharer actually picked. - The rename caveat was added two sections below the sentence it retracts. A reader renaming labels lands in Options, where the unqualified all-clear still stood, so the caveat now lives there too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* docs: address review feedback on #11686 #11686 was merged while five review comments were still open. This applies all of them. - The new "affects only this schedule" callout used <Note>, which docs-mintlify/CLAUDE.md reserves for plan availability. It is a general note, so it becomes <Info>. Left the page's actual plan callout alone; converting those is a separate sweep. - "schedules that email individual recipients" predates the change but now contradicts the paragraph above it, which has just explained that a group reaches you without an individual row. Now "schedules that send email". - The Frequency -> Schedule rename left "frequency" in two sentences of Duplicating a schedule, and the renamed heading arrived with no line naming the control. Both fixed. - Tightened the group member-count sentence: it made two claims at once where one, phrased around what a reader would actually notice (a count lower than the group's membership), carries the same information. - Trailing newline on scheduled-refreshes.mdx. * docs: name the schedule control consistently when duplicating The previous commit's rename left "schedule" doing two jobs in one sentence — the object being duplicated and the field being re-entered — and dodged it in the bullet below by inventing "cadence", a third name for a control the UI calls Schedule. Both now bold **Schedule** as the control name, which disambiguates it from the object without adding a term.
* docs(dashboards): address the review on the control-URL section Follow-up to #11687, which I merged on green checks before reading the review that had landed two minutes earlier. All five findings hold; four are mine, one is pre-existing. - The granularity list said `day`…`year`, contradicting *Allowed granularities* on the same page: `second`, `minute` and `hour` are offered for `TIMESTAMP` / `DATETIME` dimensions, so a reader building an hourly `tg_` link would have concluded the parameter couldn't express it. Both pages now name the sub-day grains and point at the switcher's allowed list as the authority. - "Published dashboards only" read as scoping the whole feature, contradicting the embed page's "works on both regular and published dashboards". Both are true — the restriction is on the outbound write, not the inbound read — so the bullet now says which direction it constrains. - The section said the children's values travel but not what the recipient's PARENT dropdown shows. Confirmed against the implementation: a parent's selection is runtime-only state and never serialized, so it falls back to the widget's saved `defaultOptionId`. Documented, because a recipient seeing the children set while the parent reads something else looks like a bug. - The link text still said "Pre-set dashboard filters via URL" after this work renamed that heading to include granularities. - The embed example carries raw `{`, `"` and `}`. Pre-existing, but that section is now the canonical reference for hand-written links, so it says to percent-encode when building the URL programmatically. Also unwrapped the new prose to one paragraph per line, matching the rest of `controls.mdx` (the hard-wrapped block would have made every later diff there noisier). * docs(embedding): finish the direction, encoding and link fixes Three low-severity follow-ups from the review of the previous commit, all on the embed page and all in text this work already touched: - The "reverse direction works too" paragraph still claimed write-back without the published-only qualifier — the same contradiction the controls page just had fixed on its read side, surviving here on the write side. - The percent-encoding note pointed at "constructing the URL programmatically", but the failure a reader will actually hit is pasting the example into the `src="…"` of the iframe snippet directly above it, where the raw quote closes the attribute and truncates the URL. Says that instead. - "the switcher's allowed granularities" is now a link, as it already is in the parallel sentence on the controls page; a reader here had no way to reach the list. --------- Co-authored-by: Gleb <gleb@unknownd2d4c7120595.localdomain>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )