-
Notifications
You must be signed in to change notification settings - Fork 2.1k
docs: document undocumented recent Cube Cloud features #11444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -340,6 +340,14 @@ Query History export. | |
|
|
||
| </Note> | ||
|
|
||
| ### Redacting exported query values | ||
|
|
||
| To keep filter values and SQL literals from leaving through Query History export, | ||
| enable **Redact filter values in Query History Export** under **Settings → | ||
| Monitoring Integrations** (shown once log export is on). With this toggle on, the | ||
| exported `api_query` field has filter values and SQL literals stripped; it's off | ||
|
Comment on lines
+343
to
+348
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Content is accurate and well-scoped. One gap: the field table above (line ~326) documents Nit: the placement puts this after the |
||
| by default. | ||
|
|
||
|
|
||
| [ref-autosuspend]: /admin/deployment/auto-suspension#effects-on-experience | ||
| [self-sinks-for-metrics]: #configuration-sinks-for-metrics | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -58,9 +58,10 @@ Shows a value relative to a target as a progress bar or circle. Useful for goal | |
| | **Target field / row** | The goal or maximum value | | ||
| | **Style** | Bar or circle | | ||
| | **Color** | Fill color for the progress indicator | | ||
| | **Format** | Number formatting applied to the target/goal text | | ||
|
|
||
| <Tip> | ||
| To compare against a static number like a quarterly goal, add a calculated field that always returns that number and use it as the **Target** field. | ||
| To compare against a static number like a quarterly goal, toggle **Use custom goal** and enter the number directly — no calculated field needed. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Tip now points at a Use custom goal toggle, but the settings table right above it (lines 55–61) doesn't list that toggle — so the one place a reader scans for available settings omits the very control the Tip tells them to use. Worth adding a row, and noting there that Target field / row is what's used when the toggle is off. Also, the two new Format rows describe different things — Progress bar's says "applied to the target/goal text", Sparkline's says "applied to the headline value". If the underlying setting is per-block number formatting in both cases (like line 30's Number block row), the asymmetric wording will read as two different features. If they genuinely differ, ignore this. |
||
| </Tip> | ||
|
|
||
| {/* TODO screenshot: Progress bar block (bar style) and circle style (hidden — replace this comment with <Frame><img src="..." /></Frame> when image is ready) */} | ||
|
|
@@ -77,6 +78,7 @@ Renders a compact trend chart — either a bar or line — within the KPI tile. | |
| | **Height / Width** | Dimensions of the sparkline in the tile | | ||
| | **Max points** | Limits the number of data points rendered | | ||
| | **Colors** | Line/fill colors | | ||
| | **Format** | Number formatting applied to the headline value | | ||
|
|
||
| {/* TODO screenshot: Sparkline block showing a trend line (hidden — replace this comment with <Frame><img src="..." /></Frame> when image is ready) */} | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -94,3 +94,5 @@ The legend appears when a Color channel is assigned. Configure it in the **Legen | |||||||||||||||
| | **Hidden** | Remove the legend entirely | | ||||||||||||||||
|
|
||||||||||||||||
| {/* TODO screenshot: legend position options (hidden — replace this comment with <Frame><img src="..." /></Frame> when image is ready) */} | ||||||||||||||||
|
|
||||||||||||||||
| Click a legend item to hide that category from the chart — the chart rescales over what's left, and the hidden item stays in the legend, dimmed. Click it again to bring it back. This is view-only: it doesn't change the underlying query, and reloading the page restores every category. | ||||||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Accurate, but it's a four-clause run-on sentence in a page that otherwise uses tables and short paragraphs. Splitting it also lets the important caveat stand on its own:
Suggested change
Also worth confirming whether hidden categories persist when the report is saved or added to a dashboard — "reloading the page restores every category" answers the reload case but not the save case, which is the one a report author will hit. |
||||||||||||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -121,9 +121,16 @@ page, or viewing a dashboard never re-runs anything on its own. | |
|
|
||
| ## On dashboards | ||
|
|
||
| Python reports render their **saved output** on dashboards. Nothing re-runs on | ||
| dashboard load, so a dashboard full of Python reports costs no compute to open — | ||
| each widget shows whatever the last **Run** produced. | ||
| A python widget re-runs its script under the **viewer's own security context** when | ||
| a dashboard is opened, rather than showing the report's saved output — this keeps | ||
| row-level security correct, since a stored result would otherwise leak whatever | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The rewrite is correct, but two other statements in this same file now contradict it and weren't updated:
This matters more than the other nits: the stale Warning is a security-behavior claim, and readers making access-control decisions will act on it. Suggest scoping both to the workbook-report path and cross-referencing the dashboard behavior, e.g. line 119 → "Opening the report or reloading the page never re-runs anything on its own; dashboards are different", and the Warning → note that the run-time-RLS caveat applies to the saved result shown in the workbook, while dashboard widgets re-run per viewer. Line 28 ("renders the saved output without re-running") is arguably fine since it's about the report, but a "(on dashboards it re-runs — see below)" would remove the ambiguity. |
||
| rows the person who last pressed **Run** could see. Dashboard filters and time | ||
| grains flow into the re-run as well, on the builder, published dashboards, and | ||
| embeds. | ||
|
|
||
| This has a real compute cost: the first person to open a dashboard triggers a | ||
| sandbox run per python widget. Repeat views within 5 minutes reuse a cached | ||
| result, shared across viewers with the same filters and identity. | ||
|
|
||
| A python widget can be opened in [Explore](/docs/explore-analyze/explore) from a | ||
| dashboard and run from there. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -294,7 +294,7 @@ can change their values, switch operators, or remove them entirely. | |
|
|
||
| Each entry has a `member` (a dimension or measure exposed by the view), an | ||
| `operator`, and a list of `values` — or a single `value`, which is natural for | ||
| single-value operators. Null-check operators take no value. | ||
| single-value operators. Null-check and empty-check operators take no value. | ||
|
|
||
| <Info> | ||
|
|
||
|
|
@@ -369,7 +369,7 @@ Operators use the same labels data consumers see in the workbook filter bar — | |
| what you see in the filter bar is what you type: `is`, `is not`, `after date`, | ||
| `after or on date`, `before date`, `before or on date`, `between`, `contains`, | ||
| `not contains`, `starts with`, `not starts with`, `ends with`, `not ends with`, | ||
| `is null`, `is not null`. | ||
| `is null`, `is not null`, `is empty`, `is not empty`. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Two things worth checking here:
|
||
|
|
||
| Operators are case-insensitive and whitespace-tolerant. Internal type names and | ||
| REST API aliases (e.g. `equals`, `gte`, `inDateRange`) are also accepted. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch on the stale claim. Two suggestions:
data_sourcestop resolving" — "stop resolving" is vague for what is effectively a breaking action. What does the user actually see: a build error, a query-time error, the deployment failing to start? Naming the symptom makes this a real warning rather than a hint.<Warning>rather than a plain paragraph — deleting the default source silently breaks every cube without an explicitdata_source, and that's easy to skim past mid-paragraph.Also worth confirming the parenthetical: "
CUBEJS_DB_*and equivalent driver-specific prefixes" — the page's own Source name rules mention_db,_aws,_jdbcsuffix collisions, so if deletion is prefix-matching there may be edge cases where it clears more or less than expected.