Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
Original file line number Diff line number Diff line change
Expand Up @@ -23,9 +23,11 @@ the driver's error and saves nothing.
## Editing and deleting

Use the **Edit** action on a row to update credentials, or the **Delete**
action to remove a named source. The **default** source can be edited but
not deleted — to remove it, clear the bare `CUBEJS_DB_*` variables from
[**Settings → Environment Variables**][ref-config-ref-env] by hand.
action to remove a source — including the **default** source. Deleting the
default source clears only its connection variables (`CUBEJS_DB_*` and
equivalent driver-specific prefixes); deployment-wide variables and other
sources are left untouched. Cubes that don't set an explicit `data_source`
stop resolving until a new default source is added.
Comment on lines 25 to +30

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.

Good catch on the stale claim. Two suggestions:

  • "Cubes that don't set an explicit data_source stop 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.
  • Given the blast radius, this is a good candidate for a <Warning> rather than a plain paragraph — deleting the default source silently breaks every cube without an explicit data_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, _jdbc suffix collisions, so if deletion is prefix-matching there may be edge cases where it clears more or less than expected.


## Source name rules

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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

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.

Content is accurate and well-scoped. One gap: the field table above (line ~326) documents security_context as "Security context of the request, represented as a string", which is the other field in the export that routinely carries sensitive values (user ids, tenant ids, emails). Since this section frames the toggle as "keep values from leaving through Query History export", a reader will reasonably assume it covers security_context too. Explicitly stating that it affects api_query only — and that security_context is exported unredacted — closes that gap.

Nit: the placement puts this after the <Note> about the analysis recipe. Reads slightly better directly after the field table, before the recipe pointer.

by default.


[ref-autosuspend]: /admin/deployment/auto-suspension#effects-on-experience
[self-sinks-for-metrics]: #configuration-sinks-for-metrics
Expand Down
9 changes: 9 additions & 0 deletions docs-mintlify/admin/users-and-permissions/manage-users.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,15 @@ You cannot delete your own account. Deleting a user is irreversible.

</Warning>

## Effective access

A user's page shows a read-only **Effective access** section listing which source
grants each piece of access the user has — a default role, a directly assigned
role, a directly assigned policy, or a group. This is useful for answering "why
can this user do that?" without piecing it together from the roles, groups, and
policies pages separately. Admins can view this for any user; users can view it
for themselves.

## Provisioning users via SCIM

If your organization uses an identity provider such as [Okta][ref-okta] or
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.

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 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) */}
Expand All @@ -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) */}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.

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.

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
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.
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.

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
Expand Up @@ -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

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 rewrite is correct, but two other statements in this same file now contradict it and weren't updated:

  • Line 119 (just above this section): "Run is the only way the saved result changes. Opening the report, reloading the page, or viewing a dashboard never re-runs anything on its own." — "or viewing a dashboard" is now false.
  • Lines 141–148, the "Who the analysis runs as" <Warning>: "Python runs with the security context of the person who pressed Run… Row-level security is applied at run time, not at view time. A user with broad access can Run, and the stored output is then readable by people whose own access is narrower." — that's exactly the leak this change fixes for dashboards. As written, a reader hits the warning after your new section and can't tell which one is current.

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.

Fix this →

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.
Expand Down
4 changes: 2 additions & 2 deletions docs-mintlify/reference/data-modeling/view.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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>

Expand Down Expand Up @@ -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`.

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 things worth checking here:

  1. This paragraph opens with "Operators use the same labels data consumers see in the workbook filter bar", but docs/explore-analyze/dashboards/widgets/controls.mdx:21 still lists the String operator set as ending at is null, is not null. If is empty / is not empty are available in the filter bar too, that table is now incomplete; if they're default_ui_filters-only, the "same labels as the filter bar" framing is slightly off for these two.
  2. is empty / is not empty aren't explained anywhere on the page. is null is self-evident; is empty is not — a reader can't tell whether it means empty string, empty string or null, or empty array on a multi-value member. One clause distinguishing it from is null would make this actionable.

Fix this →


Operators are case-insensitive and whitespace-tolerant. Internal type names and
REST API aliases (e.g. `equals`, `gte`, `inDateRange`) are also accepted.
Expand Down
Loading