diff --git a/agents/visibility.mdx b/agents/visibility.mdx index 127cc53f7..0a6a1bffe 100644 --- a/agents/visibility.mdx +++ b/agents/visibility.mdx @@ -37,6 +37,8 @@ Every agent conversation, in the Lightdash app or Slack, is visible to admins un /> +To see usage across the whole organization, select **Insights** on the **Threads** page. It opens the **AI Agents Insights** dashboard, which summarizes AI agent usage for your organization. Only organization admins can open Insights. Admins who see **Threads** for the projects they manage can't open it. + ## MCP activity The **MCP → Analytics** page covers both directions of MCP activity: external assistants calling tools on the [Lightdash MCP server](/agents/lightdash-mcp), and Lightdash agents calling tools on [connected external MCP servers](/agents/connect-external-mcp-servers). Admins can see what was called, by whom, and whether it succeeded. diff --git a/embed/react-sdk.mdx b/embed/react-sdk.mdx index 9fc7cb3d6..b82d8ea60 100644 --- a/embed/react-sdk.mdx +++ b/embed/react-sdk.mdx @@ -1407,6 +1407,10 @@ Pass the `paletteUuid` prop to the `Lightdash.Dashboard` component: Filters can be passed to `` to filter dimensions by values. Filters are applied as AND operations, each further restricting results. The Chart and Explore components do not support the `filters` prop. +When you pass `filters`, they replace the dashboard's saved dimension filters for that embed instead of adding to them. [Locked](/explore/dashboards/filter#locking-dashboard-filters) saved filters are the exception: they stay applied, and an SDK filter on a locked field is ignored. + +Each SDK filter applies to every tile that has a field with the same name and type as the `model` and `field` you pass. Any per-tile targets set on the dashboard filter's **Tiles** (or **Tabs & tiles**) tab aren't used. A tile with no matching field isn't filtered. + For the `filters` prop to work, your JWT must have `dashboardFiltersInteractivity` set to `enabled: 'all'`. Without this configuration, filters will not be applied. diff --git a/explore/configure-charts.mdx b/explore/configure-charts.mdx index 1121c4f73..e8a69d6c7 100644 --- a/explore/configure-charts.mdx +++ b/explore/configure-charts.mdx @@ -34,6 +34,12 @@ The options available in here will depend on the data in your chart. But, in her - Show value labels or group totals on data points - Hide a series from your chart +### Value label position + +Use the **Value labels** dropdown on a series to choose where its labels sit: **Hidden**, **Top**, **Bottom**, **Left**, **Right**, or **Inside**. **Hidden** turns the labels off. + +The position is set per series, so different series on the same chart can use different positions. For a grouped series, the dropdown on the group sets every series in it, and shows **Mixed** when the series in the group use different positions. Expand the group to set the position of one series. + ### Value label colors When you show value labels on bar, line, area, or pie charts, Lightdash chooses a label color automatically: diff --git a/explore/learn.mdx b/explore/learn.mdx index c9cd83f57..ff6e07f32 100644 --- a/explore/learn.mdx +++ b/explore/learn.mdx @@ -14,7 +14,7 @@ Learn is a library of guided walkthroughs inside Lightdash. Each walkthrough tea Click the **Learn** icon (a graduation cap) in the top bar, beside notifications and help. The library opens with the walkthroughs available to you. -The first time anyone in your organization opens Learn, it asks for an organization admin to enable it. Once an admin has, every walkthrough is open to everyone in the organization. +The first time anyone in your organization opens Learn, it asks for an organization admin to enable it. Once an admin has, every walkthrough is open to everyone in the organization who has access to Learn. Every built-in organization role has access; on a custom organization role, access needs the [`view:Learn` scope](/workspace-admin/custom-roles#learn-scope). ## Enable Learn for your organization diff --git a/integrations/connect-project.mdx b/integrations/connect-project.mdx index 9d3d2ba2f..d3949e38f 100644 --- a/integrations/connect-project.mdx +++ b/integrations/connect-project.mdx @@ -184,6 +184,10 @@ If you need to provide access to data across multiple BigQuery projects, the ser Once you have a service account all ready to go, you'll need to add its JSON key file to Lightdash in the `key file` section of the Warehouse Connection page. +##### Data set + +This is the name of your dbt dataset: the BigQuery dataset where the output of your dbt models is written to. It's required, and it must match the `dataset` value in your dbt `profiles.yml` file. When you pick a data set from the list, Lightdash fills in its **Location** for you. + ##### Location The data location of the dataset in BigQuery where the output of your dbt models is written to. @@ -192,6 +196,8 @@ The data location of the dataset in BigQuery where the output of your dbt models You can find the location of the dataset you're using for your dbt project [in your dbt profiles.yml file](https://docs.getdbt.com/reference/warehouse-profiles/bigquery-profile#dataset-locations), or in your BigQuery console. +Every query from this connection runs in this location. If you connect [multiple dbt sources](/integrations/dbt/projects#connecting-multiple-dbt-sources), their datasets need to be in the same location for joins between them to work. + A BigQuery Data set info panel with the Data location row reading US diff --git a/integrations/dbt/projects.mdx b/integrations/dbt/projects.mdx index 1c2ef3776..3fe37b77d 100644 --- a/integrations/dbt/projects.mdx +++ b/integrations/dbt/projects.mdx @@ -265,6 +265,8 @@ All sources are compiled together into one set of Explores, so tables from diffe All sources share the Lightdash project's warehouse connection. On a project with [multiple warehouse connections](/workspace-admin/multiple-warehouse-connections), you can run an additional source on another connection. +On BigQuery, a connection runs every query in the [location set on the connection](/integrations/connect-project#bigquery), and one query can't read datasets from different locations. Joins between models from different sources only work when their datasets are in the same location. + ### Adding and managing sources Go to **Project settings → dbt connection**. When the feature is enabled for your org, you'll see a **dbt sources** panel that lists the primary source plus any additional ones. Each row shows the source's display name and its git identity (`repository · branch · subfolder`), or the connection type for non-git sources. diff --git a/self-host/enterprise-features.mdx b/self-host/enterprise-features.mdx index ed1220781..8d9b35dee 100644 --- a/self-host/enterprise-features.mdx +++ b/self-host/enterprise-features.mdx @@ -125,7 +125,7 @@ LIGHTDASH_IFRAME_EMBEDDING_DOMAINS=https://app.example.com,https://reports.examp CUSTOM_ROLES_ENABLED=true ``` -Restart the backend. Admins can then build and assign roles from **Organization settings → Roles**. +Restart the backend. Organization admins can then build and assign roles from **Settings** → **Custom roles** (under **Organization settings**). ### Service accounts diff --git a/support/support-access.mdx b/support/support-access.mdx index 3ffab6809..b6c977fb5 100644 --- a/support/support-access.mdx +++ b/support/support-access.mdx @@ -27,14 +27,15 @@ When a user is impersonated: Impersonation by organization admins is behind a feature flag. On Lightdash Cloud, [contact support](mailto:support@lightdash.com) to enable it for your organization. Self-hosted instances enable it themselves, as described below. -Only **organization admins** can impersonate other users, and only users inside their own organization. Once the feature is available, admins enable it from the organization settings and can turn it off at any time. +Only **organization admins** can impersonate other users, and only users inside their own organization. Once the feature is available, an organization admin goes to **Settings** → **General** (under **Organization settings**) and turns on **Enable user impersonation** in the **User impersonation** section. Turn it off there at any time. **Self-hosted instances** turn on the feature flag themselves: 1. Add `user-impersonation` to the `LIGHTDASH_ENABLE_FEATURE_FLAGS` environment variable. The value is a comma-separated list of flag IDs, so if you already set it, append the ID, for example `LIGHTDASH_ENABLE_FEATURE_FLAGS=embedding,user-impersonation`. See [feature flags](/self-host/customize-deployment/environment-variables#feature-flags). 2. Restart Lightdash so the new value takes effect. - 3. An organization admin goes to **Settings** → **General** (under **Organization settings**) and turns on **Enable user impersonation** in the **User impersonation** section. + + An organization admin then enables impersonation in the organization settings, as described above. diff --git a/workspace-admin/custom-roles.mdx b/workspace-admin/custom-roles.mdx index 8bbc44a4a..e85744cb4 100644 --- a/workspace-admin/custom-roles.mdx +++ b/workspace-admin/custom-roles.mdx @@ -373,6 +373,10 @@ Combine this with the [content-as-code preview restriction](#restrict-developers The **Agent permissions** group in **AI Features** limits what AI agents can do for people with the role. See [Agent permissions](/agents/agent-permissions#custom-roles). +### Learn scope + +The `view:Learn` scope (description: *View and use Learn walkthroughs*), in the **Organization Management** group, controls who can see and open [Learn](/explore/learn). Every built-in organization role includes it. Users whose organization role is a custom role only see Learn if that role includes `view:Learn`, so you can roll Learn out to some roles first. Adding the scope to a project-level custom role doesn't grant access. + ### SQL-related scopes Three scopes control different SQL-authoring features. They are independent — granting one does not grant the others. diff --git a/workspace-admin/export-limits.mdx b/workspace-admin/export-limits.mdx index 75f794bf6..721b569bb 100644 --- a/workspace-admin/export-limits.mdx +++ b/workspace-admin/export-limits.mdx @@ -51,7 +51,7 @@ Changes take effect immediately for new queries and exports. Existing scheduled | Surface | Behavior | | --- | --- | | Explorer and SQL runner row-limit selector | Maximum value is clamped to the org's effective query row limit. | -| CSV and Excel downloads from charts, dashboards, and underlying data | Truncated to the org's effective cell limit, with a banner shown when truncation happens. | +| CSV and Excel downloads from charts, dashboards, and underlying data | Truncated to the org's effective cell limit. When truncation happens, a warning notification, **The results in this export have been limited.**, shows for about 5 seconds and then closes. | | Scheduled deliveries (CSV, Google Sheets, Excel) | Use the org's effective cell limit at run time. | | API responses for `/api/v1/org/settings` | Return the resolved effective values, falling back to the instance defaults when no override is set. | diff --git a/workspace-admin/usage-analytics.mdx b/workspace-admin/usage-analytics.mdx index 21c0cf136..a55bb8735 100644 --- a/workspace-admin/usage-analytics.mdx +++ b/workspace-admin/usage-analytics.mdx @@ -71,7 +71,7 @@ The following query tags are sent: | scheduler_uuid | Scheduler unique identifier. Only set when the query is triggered by a scheduled delivery, alert, or Google Sheets sync. | | scheduler_name | Human-readable name of the scheduler. Only set when the query is triggered by a scheduler. | | job_id | Scheduler job identifier for a single run of a scheduler. Only set when the query is triggered by a scheduler. | -| app_uuid | [Data app](/data-apps) unique identifier. Lightdash sets it automatically when the query originates from a running data app. | +| app_uuid | [Data app](/data-apps) unique identifier. Lightdash sets it automatically when the query originates from a running data app. The value is reported by the app itself in a request header and isn't verified by the server, so treat it as a best-effort attribution signal for usage reports. | | query_context | Which context the query was executed in. See [Query contexts](#query-contexts) below for the full list of values. | | agent | `true` when an AI agent ran the query. Set with [agent identity](/agents/agent-identity#find-agent-queries-in-the-warehouse). | | agent_surface | Where the AI agent ran, for example `mcp` or `slack_agent`. Only set with [agent identity](/agents/agent-identity#find-agent-queries-in-the-warehouse). |