Skip to content

docs: fill four gaps found in a customer-facing feature sweep #11565

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.

Sign up for GitHub

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

Open
keydunov wants to merge 1 commit into
base: master
Choose a base branch
from
Open

docs: fill four gaps found in a customer-facing feature sweep #11565

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs-mintlify/docs/explore-analyze/charts/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,8 @@ Chart type icons at the top of the chart panel let you quickly switch between co

Cube automatically picks a chart type when you run a new query. Any manual configuration you apply is preserved when you change query fields.

If a later change to the query — like removing a dimension or measure — leaves the applied chart type unable to render the result, Cube shows a warning naming the chart type and what it still needs. From there you can undo the change that broke it or pick a different chart type that fits the current query.

### Resetting chart settings

To discard your configuration and let Cube re-select a chart type based on the current query, open the tab options menu and choose **Reset chart**.
Expand Down
5 changes: 4 additions & 1 deletion docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,8 @@ Set the visibility from the **Visibility** dropdown when editing the control. **

When a control is added to a dashboard, it's automatically wired up to every [chart][ref-charts] whose query already uses the same dimension. Charts that don't reference that dimension are left alone, so a dashboard can mix scoped and unscoped views by default. You can override this default per chart from its [Controls mapping](#controls-mapping) — disable the control for that chart, or remap it onto a different dimension.

The reverse case — adding a chart from a different semantic view than the dashboard's existing controls (a **cross-view** chart) — isn't wired up automatically, since a same-named dimension on another view isn't necessarily the same dimension. Instead, Cube prompts you to review it: a banner names how many controls could apply, and **Review…** opens [Controls mapping](#controls-mapping) with a suggested dimension already picked for each match. Save to connect them, or **Dismiss** the banner to leave the chart unconnected. A confirmation after saving lets you **Undo** the connection.

### Incompatible controls

If controls of a certain type are incompatible with a particular chart's query, the chart skips all controls of that type and renders the data without them. Controls of the other type still apply — for example, if filters fail but a time granularity switcher works, the chart shows the granularity-adjusted data without filtering, and vice versa.
Expand All @@ -130,12 +132,13 @@ Open **Controls mapping** from a chart's settings menu to inspect or override th
- **Toggle the control on or off** for the chart, even when a mapping exists
- **Pick a different dimension** from the chart's semantic view to remap the control to

Three states show up in the mapping sidebar:
Four states show up in the mapping sidebar:

| Status | What it means |
|---|---|
| **Mapped automatically** | The control's dimension exists on the chart's semantic view, so it's wired up without configuration. |
| **Manually mapped** | You (or an AI agent) picked a specific dimension for this chart. **Reset** restores the automatic mapping. |
| **Suggested mapping** | Cube found a matching dimension on a cross-view chart but hasn't applied it yet — save to apply it, or pick a different dimension. |
| **Can't map automatically** | The control targets a dimension that doesn't exist on the chart's semantic view. The chart is unaffected by the control until you map it manually. |

For [time granularity switchers][ref-time-grain], the dimension picker is restricted to time-typed dimensions on the chart's semantic view, since other dimension types can't be resolved by the time granularity pipeline.
Expand Down
4 changes: 3 additions & 1 deletion docs-mintlify/docs/explore-analyze/workbooks/querying-data.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -219,7 +219,9 @@ granularity — a month grain offers **Previous period**, **Same period
previous quarter**, and **Same period previous year** — so the comparison
period always aligns exactly with the current buckets. A measure can have
several comparisons active at once, such as month over month and year over
year side by side.
year side by side. If the query has more than one time dimension, the same
comparison can also be applied under each of them independently — each
combination gets its own derived columns.

Each comparison adds derived columns next to the measure. Choose which ones
to show under **Comparison columns** in the same menu:
Expand Down
14 changes: 14 additions & 0 deletions docs-mintlify/docs/integrations/dbt.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -404,6 +404,20 @@ deployment is shown in the dbt settings card, ready to drop into a CI step.
/>
</Frame>

The trigger call accepts an optional `ref` — a branch or tag in your dbt repository —
to sync from for that call only, without changing the branch saved on the
integration. Use it in a pull request pipeline to test the ref under review before it
merges.
Comment on lines +407 to +410

@claude claude Bot Aug 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ref parameter is described but not shown — a reader can't act on this without knowing where it goes (query string vs. JSON body) and what the trigger's HTTP method is. Neither is stated anywhere on the page, and the screenshot above only shows the URL.

Worth one short concrete line, e.g. POST .../dbt-sync?ref=my-branch or a {"ref": "my-branch"} body — whichever matches the implementation.

Fix this →


The response includes a `syncJobId`, which a pipeline can use to wait on the sync
instead of firing the trigger and moving on blind:

| Call | What it does |
| --- | --- |
| `GET .../dbt-sync/{syncJobId}` | Returns the sync's current `status`. Poll it until `status` reaches `COMPLETED` or `FAILED`. |
| `GET .../dbt-sync/{syncJobId}/result` | Once `status` is `COMPLETED`, returns the generated cube files and cube count. |
| `DELETE .../dbt-sync/{syncJobId}` | Cancels a sync that's still running — for example, when a newer push supersedes it. |
Comment on lines +415 to +419

@claude claude Bot Aug 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two small things in this table:

  1. The .../ prefix is doing a lot of implicit work. The paragraph two above says the trigger URL is in the settings card, but nothing states that these paths are relative to that same URL. A half-sentence lead-in ("…using the same endpoint URL shown above:") would remove the guesswork.
  2. status is only partially enumerated — COMPLETED and FAILED are named as terminal, but a poller also needs to know what it will see in the meantime (PENDING/RUNNING/whatever the API returns), and whether cancellation surfaces as a distinct terminal status. As written, "poll until status reaches COMPLETED or FAILED" could loop forever on a cancelled job.

Fix this →


### Trigger on every push

Register a webhook on your dbt repository so Cube syncs automatically whenever the
Expand Down
Loading