[pull] master from cube-js:master

docs-mintlify/docs/explore-analyze/charts/chart-types/table.mdx

@@ -49,6 +49,8 @@ with the header showing the dimension's value once instead of on every row under
 Turning it on also adds a **Row grouping** section to the **Style** tab, with:
 
 - **Expand all groups** / **Collapse all groups** — set every group's expand state at once.
+- **Subtotals** (Σ) — show an aggregated value for every measure on each group header row.
+  See [Per-group subtotals](#per-group-subtotals).
 - Text color, background color, and text formatting for the group header rows.
 
 Each group-level column's card in the **Columns** section gets a **Default state**
@@ -58,6 +60,31 @@ individual group isn't affected by changing it afterwards.
 
 {/* TODO screenshot: table with collapsed row groups and the Style tab's Row grouping section */}
 
+### Per-group subtotals
+
+With grouping on, the **Subtotals** (Σ) toggle in the **Row grouping** section adds an
+aggregated value for every measure to each group header row, at every nesting level. Not
+to be confused with [pivot subtotals](#subtotals), which add a **Total for ‹value›**
+column per pivot group rather than a value per group header row.
+
+Each subtotal is queried at its own group's grain rather than summed from the rows below
+it. That distinction matters for any measure that doesn't add up: an `avg` shows the true
+average over the group instead of an average of averages, and a `count_distinct` counts a
+value once even when it appears in several child groups. As a result a subtotal can
+legitimately differ from the sum of the rows beneath it — for a distinct count it is
+usually smaller.
+
+It also means the value stays correct on a collapsed group, where there are no visible
+rows to add up at all.
+
+Measures built on window functions (`RUNNING_TOTAL`, `OFFSET`, or a SQL `OVER` clause)
+can't be recomputed at another grain, so their cells stay empty on group rows — the same
+exclusion that [row, column, and pivot
+totals](/docs/explore-analyze/workbooks/querying-data#subtotals) make. Period-comparison
+columns are also left empty. The toggle is disabled unless grouping is active and the
+values are placed in columns, since the values-as-rows layout has no per-measure column
+for a subtotal to sit under.
+
 ## Column field options
 
 Configure individual columns in the **Columns** section of the **Style** tab (or via the dropdown arrow on a field in the **Fields** section):
@@ -486,7 +513,7 @@ For the computed anchors (Minimum, Maximum, Midpoint, Average, Median), the drop
 
 Use **Reverse color scale** to swap the Start and End colors. **Treat nulls as zero** is on by default, coloring null/blank cells as zero; turn it off to leave them uncolored.
 
-The scale is normalized **per column** — each targeted column uses its own value range, taken from the column's data cells only. With [totals](#totals) enabled, the row totals and subtotal columns are still colored by the scale of the measure they aggregate, but they don't widen its range: a total past the column's highest stop is clamped to that stop's color. Cells in the column totals row are never colored by a scale, since totals rows don't take formatting rules.
+The scale is normalized **per column** — each targeted column uses its own value range, taken from the column's data cells only. With [totals](#totals) enabled, the row totals and [pivot subtotal](#subtotals) columns are still colored by the scale of the measure they aggregate, but they don't widen its range: a total past the column's highest stop is clamped to that stop's color. Cells in the column totals row are never colored by a scale, since totals rows don't take formatting rules.
 
 {/* TODO screenshot: table with a color scale applied to a numeric column (hidden — replace this comment with <Frame><img src="..." /></Frame> when image is ready) */}
 
@@ -496,4 +523,4 @@ Enable column totals and row totals from the **Totals** section of the **Style**
 
 ### Subtotals
 
-When the table is pivoted by two or more dimensions, you can also enable **subtotals** — a bold **Total for ‹value›** column appended after each pivot group's columns, at every nesting level. Subtotals combine freely with column and row totals, work in workbooks and on dashboards, and — like the other totals — carry over from the results table when you switch the chart type to Table. See [Subtotals](/docs/explore-analyze/workbooks/querying-data#subtotals) for details and limitations.
+When the table is pivoted by two or more dimensions, you can also enable **subtotals** — a bold **Total for ‹value›** column appended after each pivot group's columns, at every nesting level. Not to be confused with [per-group subtotals](#per-group-subtotals), which add a value to each row group's header row rather than a column per pivot group. Subtotals combine freely with column and row totals, work in workbooks and on dashboards, and — like the other totals — carry over from the results table when you switch the chart type to Table. See [Subtotals](/docs/explore-analyze/workbooks/querying-data#subtotals) for details and limitations.

docs-mintlify/docs/explore-analyze/dashboards/widgets/controls.mdx

@@ -36,7 +36,7 @@ You can set a default value that's applied when the dashboard loads. Defaults ar
 There are two ways to set a default:
 
 - **Static default** — pick a value (or values) directly in the filter. Every viewer sees the same default.
-- **User attribute default** — resolve the default from the viewer's [user attribute][ref-user-attributes] at load time, so each viewer sees their own personalized default.
+- **User attribute default** — resolve the default from the viewer's [user attribute][ref-user-attributes] at load time, so each viewer sees their own personalized default. [Parent controls](#default-option) support this too.
 
 Static defaults are configured by interacting with the filter in the dashboard builder — the value you select is saved on the widget and applied to every viewer when the dashboard loads.
 
@@ -147,9 +147,91 @@ Click the indicator to jump straight to the **Children** tab of the parent that
 
 ### Default option
 
-Set **Default value** to the option that should be selected when the dashboard loads. Choosing a default in the builder also applies that option's values to the children, so their saved defaults line up with the parent's and a published dashboard opens in a consistent state.
+The option a parent control opens on is the one you last picked **in the control itself on the dashboard**, not a field in its settings — the same way a filter's static default and a time granularity switcher's default are set. Pick an option in the dashboard builder and it's saved on the widget and applied to every viewer when the dashboard loads.
 
-If you leave **Default value** empty, the parent opens with nothing selected and the children use their own defaults.
+Picking in the builder also applies that option's values to the children, so their saved defaults line up with the parent's and a published dashboard opens in a consistent state.
+
+If you never pick an option, the parent opens with nothing selected and the children use their own defaults. Deleting the option that was serving as the default clears it, and the parent goes back to opening on nothing.
+
+#### User attribute default
+
+The default above is one arrangement for everyone. To give each viewer their own, turn on **User attribute default** in the parent control's settings and pick a [user attribute][ref-user-attributes]. When the dashboard loads, Cube reads that attribute for the current viewer and opens the control on the option it names — and drives the children with it, exactly as if the viewer had picked that option themselves.
+
+This is how you ship one dashboard that opens differently per audience: a **Reporting period** parent whose options are `Month` and `Quarter`, opening on whichever one the viewer's `reporting_period` attribute says, with every filter and time granularity switcher behind it already set to match.
+
+To configure it:
+
+<Steps>
+ <Step title="Open the parent control's settings">
+   In the dashboard builder, click **Configure Parent** on the control, or open its settings menu.
+ </Step>
+ <Step title="Enable User attribute default">
+   Scroll to the **User attribute default** switch and turn it on.
+ </Step>
+ <Step title="Pick the attribute">
+   Select the [user attribute][ref-user-attributes] to resolve. Only attributes defined in your account appear in the picker.
+ </Step>
+</Steps>
+
+The attribute value is matched against the **option labels**, ignoring case and surrounding spaces — an attribute reading `quarter` selects the option labelled `Quarter`. Give the options the labels your attribute already uses, or adjust the attribute values to match; renaming an option later doesn't disturb the child mappings, so labels are safe to align after the fact.
+
+| Attribute type | How it's applied |
+|---|---|
+| **String**, **Number** | Matched against the option labels as a single value. |
+| **String array**, **Number array** | The first entry that names an option wins. A parent control is single-select, so the rest are ignored. |
+
+If the value matches no option — or is empty, `null`, or unresolvable — the control falls back to the [default option](#default-option) you picked, and the children keep the arrangement that goes with it.
+
+<Note>
+The attribute is resolved for the viewer, not baked into the dashboard. Editing the attribute's value changes what that viewer opens on the next time the dashboard loads; it never rewrites the published dashboard, so the default you picked in the builder stays intact for everyone else.
+</Note>
+
+Viewers can still switch to another option unless the control's [visibility](#visibility) is set to **Disabled**, and their own pick outranks the attribute for the rest of the session. Values passed [in the URL](#sharing-the-current-selection) outrank both, so a shared link opens on the values it names rather than on the recipient's attribute.
+
+## Sharing the current selection
+
+On a published dashboard, the values a viewer picks in the controls are reflected
+in the URL, so the view they are looking at is bookmarkable and shareable. Copy
+the address bar, send it on, and the recipient opens the dashboard with the same
+filters and granularities applied.
+
+Each control type has its own parameter:
+
+| Control | Parameter | Example |
+|---|---|---|
+| [Filter](#filter) | `f_<semantic_view>.<dimension>=<JSON>` | `f_orders.status={"value":"shipped"}` |
+| [Time granularity switcher](#time-granularity-switcher) | `tg_<semantic_view>.<dimension>=<granularity>` | `tg_orders.created_at=week` |
+
+The semantic view and dimension are the **internal names** configured on the
+control — not the display titles you see in the picker. A view shown as `Orders`
+is usually `orders` in the parameter. Granularities are lowercase: `day`, `week`,
+`month`, `quarter`, `year`.
+
+You can also write these parameters by hand to open a dashboard in a particular
+state — see [Pre-set dashboard filters via URL][ref-embed-url-filters] for the
+embedded case, which uses the same format.
+
+What does and doesn't travel in the link:
+
+- **Only what the viewer chose.** Values that came from the control's own
+  configuration — a static default, a [default granularity](#default-granularity)
+  — are not written into the URL. Every viewer already gets those from the
+  dashboard itself, and leaving them out means a link stays correct after the
+  dashboard's defaults change.
+- **Never a personalized default.** A value resolved from a
+  [user attribute](#user-attribute-default) stays out of the link — whether it
+  seeded a filter directly or reached one through a [parent control](#parent)
+  opening on the viewer's own option. Sharing a dashboard never pins your
+  attribute value onto the recipient; they see it through their own attributes.
+- **Filters and granularities together.** Picking both puts both in the link,
+  including when a [parent control](#parent) sets several children at once.
+- **Published dashboards only.** In the dashboard builder the URL is left to
+  the editing session, so editing a control there doesn't rewrite it.
+
+When a dashboard opens with these parameters, they are applied on top of whatever
+defaults the controls carry. A parameter is ignored when nothing on the dashboard
+can honor it — there is no matching control for that dimension, or the requested
+granularity isn't in the switcher's [allowed granularities](#allowed-granularities).
 
 ## Visibility
 
@@ -204,6 +286,7 @@ For [time granularity switchers][ref-time-grain], the dimension picker is restri
 Mappings are also configurable by AI agents when they build or edit a dashboard, so an agent can wire controls across charts that use different semantic views without you needing to revisit each chart manually.
 
 [ref-time-grain]: #time-granularity-switcher
+[ref-embed-url-filters]: /embedding/iframe/dashboards#pre-set-dashboard-filters-via-url
 
 [ref-workbooks]: /docs/explore-analyze/workbooks
 [ref-charts]: /docs/explore-analyze/dashboards/widgets/charts

docs-mintlify/docs/explore-analyze/notifications.mdx

@@ -31,12 +31,11 @@ scratch — the copy carries over the source schedule's notification settings.
 
 ### Delivery channel
 
-Toggle between two delivery channels:
+A schedule delivers to one channel, not both. Pick it with the **Send via**
+radio buttons:
 
-- **Email** — select recipients using a searchable picker with checkboxes. The
-  picker is grouped into **Users** and **User groups** sections, so you can add
-  individual workspace users, entire [user groups][ref-user-groups], or a mix of
-  both.
+- **Email** — sends to the [recipients](#recipients) you choose: individual
+  workspace users, [user groups][ref-user-groups], or a mix of both.
 - **Slack** — select a Slack channel to post to. Requires connecting your Slack
   workspace first (one-time OAuth flow via **Connect to Slack**). Once
   connected, select a channel from a searchable picker.
@@ -75,17 +74,43 @@ from the published dashboard.
 
 ### Recipients
 
-The recipient picker is split into two sections:
+Under the **Recipients** heading there are two separate controls:
 
-- **Users** — individual workspace users.
-- **User groups** — [user groups][ref-user-groups]. A group is expanded to its
-  current members each time the notification is sent, so adding or removing
-  members takes effect on the next run without editing the schedule. The **User
-  groups** section only appears when your workspace has at least one user group.
+- **Users** — a searchable picker for individual workspace users.
+- **User groups** — a dropdown holding an expandable checklist of
+  [user groups][ref-user-groups] and their members. It appears only when your
+  workspace has at least one user group.
+
+A group is expanded to its current members each time the notification is sent,
+so adding or removing members takes effect on the next run without editing the
+schedule. The number beside a group's name is how many members it can currently
+email; a member with no email address is not listed and is never counted.
 
 A recipient who is selected individually and also belongs to a selected group is
 emailed only once.
 
+#### Excluding individual group members
+
+Tick a group to notify everyone in it, then expand it and untick anyone who
+should be skipped. Those people are stored as exceptions to that group on this
+schedule — the group stays selected and keeps picking up new members, but the
+excluded members are left out of every run.
+
+One search box filters both levels at once, so typing a person's name narrows
+the list to the groups that would notify them, with that person shown under
+each.
+
+Exceptions are saved with the rest of the form, not applied as you click. A few
+details worth knowing:
+
+- Unticking a group's **last** remaining member unticks the whole group.
+- Exceptions belong to one schedule and one group. Excluding someone from a
+  group here does not affect the group anywhere else, or any other schedule.
+- An exception is not a block on the person. If they are **also** selected under
+  **Users**, or have [subscribed themselves][ref-subscribe], they still get the
+  email — a direct recipient row and group membership are independent, and
+  either one alone delivers.
+
 ## Slack notifications
 
 Slack notifications post a message with the dashboard screenshot to a single

docs-mintlify/docs/explore-analyze/scheduled-refreshes.mdx

@@ -48,7 +48,7 @@ The dashboard must be published before schedules can be created.
 Click **New scheduled refresh** in the sidebar footer. A dialog opens
 with the following configuration options.
 
-### Frequency
+### Schedule {#frequency}
 
 | Option | Description |
 | --- | --- |
@@ -122,20 +122,37 @@ If a schedule sends [email notifications][ref-notifications], anyone who can vie
 the dashboard can subscribe to it themselves — an editor does not have to add
 them as a recipient. Open the scheduled refreshes sidebar from the published
 dashboard and use the toggle on a schedule to subscribe or unsubscribe.
-Subscribing adds you to the schedule's email recipients; unsubscribing removes
-you. The change takes effect on the next run.
+
+The toggle covers **every** way that schedule could reach you, in one click. If
+you were added individually, unsubscribing removes you from its recipients. If
+you are reached through a [user group][ref-user-groups] — or several — it also
+records you as an exception to each of those groups on this schedule, so the
+group keeps notifying everyone else but stops emailing you. Subscribing reverses
+both: it clears those exceptions and adds you back as a recipient in your own
+right. The change takes effect on the next run.
+
+<Note>
+
+Unsubscribing affects only this schedule. It does not remove you from the user
+group, and it does not change any other schedule that group receives.
+
+</Note>
 
 The toggle appears only for schedules that email individual recipients — those
 with notifications enabled and the email delivery channel. A schedule delivers to
 either individual inboxes or a Slack channel, not both, so a schedule that posts
 to Slack (or that has notifications turned off) has nothing to subscribe to. If an
-editor switches a schedule to Slack, its existing subscriptions are cancelled;
-you can subscribe again if it is later switched back to email.
+editor switches a schedule to Slack, its individual subscriptions are cancelled
+and any group exceptions it held are cleared; if it is later switched back to
+email, everyone starts from the group's full membership again and can subscribe
+or unsubscribe afresh.
 
 Every notification email also includes a one-click **Unsubscribe** link in its
 footer, so a recipient can stop receiving a schedule's emails without signing in
-to Cube. This works for any recipient, including those added directly by an
-editor and embed users who have no Cube account of their own.
+to Cube. It behaves exactly like the toggle, covering both a direct recipient row
+and any [user group][ref-user-groups] delivering to you. This works for any
+recipient, including those added directly by an editor and embed users who have
+no Cube account of their own.
 
 ## Run phases
 
@@ -150,4 +167,5 @@ When a scheduled refresh runs, it progresses through these phases:
 The sidebar shows real-time status updates during execution.
 
 [ref-roles]: /admin/users-and-permissions/roles-and-permissions
-[ref-notifications]: /docs/explore-analyze/notifications
+[ref-notifications]: /docs/explore-analyze/notifications
+[ref-user-groups]: /admin/users-and-permissions/user-groups