https://www.gooddata.ai/ logo
Join Slack
Powered by
Hi GoodData team! In the previous version of GoodD...
# gooddata-cloud
s
Hi GoodData team! In the previous version of GoodData that we used, we had the Variables feature, which allowed us to create visualization variables/filters and assign them to specific users. This enabled us to control which data each user could see and ensure proper data segregation. In our current GoodData Cloud version, we identified User Data Filters (UDF) as a possible alternative for this use case. However, when accessing this functionality, the platform displays a message indicating that the feature is currently in Early Access. We will also attach a screenshot of this message for reference. Since we intend to use this functionality to restrict data visibility on a per-user basis, we would like to better understand the current maturity and security of this feature. Could you please clarify: • What is the current development/maturity stage of User Data Filters? • Does GoodData recommend using this feature in production environments? • Since the feature is currently classified as Early Access, are there any known risks or limitations that could cause the filters to fail and potentially expose data that a user should not be able to access? • Does GoodData consider UDF a secure mechanism for data segregation and user-level data access control, or is there another feature currently recommended for this use case? • Is there an estimated timeline for UDF to move from Early Access to a stable/GA (General Availability) status? Our main concern is ensuring that a user can never access data that they are not authorized to see. Therefore, we need to understand whether User Data Filters can be considered a reliable access-control mechanism for a production environment. Thank you!
k
Thinking completed It is important to distinguish between User Data Filters (UDF) as an underlying data security feature and User Data Filter Management in the UI shown in your screenshots. Here is the breakdown addressing your questions: 1. Maturity Stage and Production Readiness • The Core UDF Feature is Fully Released (GA): User Data Filters as an underlying data access control and security mechanism were released in April 2023 and are fully supported for production use [GoodData Cloud Release]. They can be configured and managed via API. • What is in Early Access / Experimental is Only the UI: The preview dialog shown in your screenshot refers strictly to Manage User Data Filters in the UI (navigating to Workspaces > Workspace Settings > User Data Filters) [Manage User Data Filters]. Because creating and managing filters was previously API-only, GoodData introduced an experimental UI to make inspecting, creating, and editing filters easier. While the UI tool itself is experimental, the filter engine enforcing the security rules is not. 2. Is UDF a Secure Mechanism for Data Segregation? Yes. User Data Filters (along with Workspace Data Filters) are GoodData’s recommended, officially supported approach for row-level security and user data segregation [Community Slack]. • UDFs enforce row-level security across the platform using MAQL expressions [Set Up Data Filters]. • They propagate through relationships defined in your Logical Data Model (LDM) along the direction of the arrows [Set Up Data Filters]. • They apply whether users view data via the UI or query it programmatically via API tokens [Community Slack]. In contrast, dashboard filters are not considered a security mechanism, as API calls can bypass them [Community Slack]. 3. Known Limitations and Considerations When setting up and maintaining UDFs, keep the following in mind to avoid unexpected data exposure: • Explicit Configuration Required: UDFs do not apply automatically; they must be explicitly defined and assigned to each user or user group. If a user does not have a filter assigned (or does not inherit one via group membership), they will see unrestricted data in that workspace [Set Up Data Filters]. • LDM Directionality: A user data filter applies to related attributes along the oriented path of the arrows in the Logical Data Model (LDM), but not against the direction of arrows [Set Up Data Filters]. Ensure your LDM schema supports the path needed for the filter to propagate correctly. • Filter Combinations: If a user belongs to multiple user groups with different UDFs, all filters are combined using the 
AND
operator (narrowing access to the intersection) [Set Up Data Filters]. • UI Limitations: Because the UI management screen is experimental, some advanced workflows or configurations may still require using the REST API [Manage User Data Filters]. 4. Timeline for UI General Availability The documentation does not specify an exact release date or timeline for the User Data Filter Management UI to move from Experimental to General Availability (GA). How to Reach Support if Needed If you need deeper human assistance reviewing your configuration or data model: • Community support (Startup & Professional): You are already in the right place. The GoodData Support team monitors this Slack community and will join the thread directly if specialized technical or account review is required. To help the Support team investigate, please add the following details to this thread: ◦ Your workspace and organization IDs ◦ The exact MAQL expression used for your filter ◦ How the filter is assigned (user ID or user group ID) ◦ Any relevant API payloads or error responses You can also visit the Community Forums. • 24/7 Support (Enterprise plans): If your account tier includes 24/7 Support or this is a Severity 1 critical issue, direct options are available in addition to this thread: ◦ Submit a ticket: Support Portal ◦ Email: support@gooddata.com ◦ Phone: +1 (415) 200-0194 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups. 👀 Our Support team monitors all messages and will jump in if needed.
y
Hello Sheila, Please let us know if you have any further questions regarding this.
s
We embed GoodData Cloud dashboards in our React application and would like guidance on applying a core data filter at user authentication time, so every widget on the dashboard only sees data for the authenticated tenant. Current integration We use GoodData Cloud (Tiger) with the JavaScript UI SDK, version 11.35.0: • 
@gooddata/sdk-backend-tiger
• 
@gooddata/sdk-model
• 
@gooddata/sdk-ui
• 
@gooddata/sdk-ui-dashboard
(and the related UI CSS packages: 
sdk-ui-kit
, 
sdk-ui-ext
, 
sdk-ui-pivot
, 
sdk-ui-charts
, 
sdk-ui-filters
, 
sdk-ui-dashboard
) How it works today (step by step) 1. Backend / auth We create a Tiger backend with 
tigerFactory()
, point it at our GoodData Cloud hostname, and authenticate with 
TigerTokenAuthProvider
using a static API token. 2. Providers The React tree wraps the screen with 
BackendProvider
and 
WorkspaceProvider
(one shared workspace). 3. Embedding We render the 
<Dashboard>
component from 
@gooddata/sdk-ui-dashboard
in read-only mode (
config={{ isReadOnly: true }}
), passing a dashboard 
idRef
. 4. Client-side filters after load On 
GDC.DASH/EVT.INITIALIZED
and 
GDC.DASH/EVT.FILTER_CONTEXT.SELECTION.RESET
, we dispatch 
changeFilterContextSelection
with attribute filters built from the logged-in user: Tenant: a positive attribute filter on a tenant display form (the identifier differs per dashboard, e.g. 
ACCOUNT_TENANT
, 
central.central_tenant
, 
SERVICE_ORDER_TENANT
, 
occurrence_tenant
), with the value equal to our application 
tenantId
. Service type: a second attribute filter with the service-type names the user is allowed to see. This works as a dashboard filter-context change after the dashboard is already loaded. The limitation is that it is client-side, dashboard-specific (each dashboard uses a different tenant attribute/label), and child widgets do not inherit a single core isolation rule from authentication. Users can also reset filters, which we have to re-apply manually. What we need We need a core filter bound to the authenticated user, not a per-dashboard filter bar change. • The isolation key is 
tenantId
(our multi-tenant identifier). • After the user authenticates, all insights / widgets / nested (child) items on the dashboard should only return rows for that tenant. • The filter should apply at the data/query layer (or via user/workspace data permissions), so it cannot be removed from the UI and does not depend on each dashboard having its own tenant attribute in the filter context. Questions 1. What is the recommended way in GoodData Cloud (Tiger) to apply this kind of mandatory tenant isolation at authentication? 2. How should we map our application 
tenantId
to the LDM so child widgets automatically inherit that core filter, instead of us calling 
changeFilterContextSelection
per dashboard? 3. If we keep 
TigerTokenAuthProvider
with an API token, can this still be done per end-user, or do we need to switch to JWT / OIDC so each session carries the 
tenantId
claim? 4. Could you share a concrete example (auth payload + workspace/data-filter setup) for “every query on this dashboard is restricted to `tenantId = <authenticated tenant>`”?
@Yvonne Changamuka Could you help me?
y
Hi Sheila, Im reviewing this, I will get back to you as soon as possible.
Hi Sheila, Thanks for your patience. In GoodData Cloud, the core mechanism for this requirement is User Data Filters (UDFs), which provide row-level security enforced directly by the MAQL query engine. Kindly refer to our docs for more information here: Set Up Data Filters for Users. Kindly consider the following approach: Enforce Isolation at the Data/Query Layer with UDFs ◦ Instead of passing attribute filters via the UI SDK (changeFilterContextSelection), define a User Data Filter for the user or user group in the workspace . ◦ UDFs use MAQL expressions defined on an attribute label in your Logical Data Model (LDM) (e.g., {label/CUSTOMER_COUNTRY} = "Canada"). ◦ Because UDFs propagate automatically along the direction of relationship arrows in the LDM, applying a filter to a core tenant attribute propagates to all related datasets, metrics, and dashboard widgets automatically. ◦ Once applied, the filter cannot be modified, reset, or bypassed by users from the UI. Per-User Authentication Requirement ◦ To apply user-specific data filters, each session must authenticate as that specific user (for example, using per-user tokens or JWT/ OIDC authentication mapped to the individual user identity). Example setup 1. Define the User Data Filter (API) You can create a UDF in your workspace using either the Entity API or the Declarative API. Entity API payload template:
Copy code
{
  "data": {
    "type": "userDataFilter",
    "id": "<data-filter-id>",
    "attributes": {
      "maql": "<maql-expression>",
      "title": "<data-filter-name>"
    },
    "relationships": {
      "user": {
        "data": {
          "id": "<user-id>",
          "type": "user"
        }
      }
    }
  }
}
Example payload:
Copy code
{
  "data": {
    "type": "userDataFilter",
    "id": "tenant_filter_123",
    "attributes": {
      "maql": "{label/tenant_id} = \"tenant_123\"",
      "title": "Tenant 123 Filter"
    },
    "relationships": {
      "user": {
        "data": {
          "id": "john.doe_tenant",
          "type": "user"
        }
      }
    }
  }
}
(Note: You can also substitute "user" with "userGroup" to assign the filter to an entire group of users .) 2. Multi-value Conditions If a tenant or user needs access to multiple values, format the MAQL expression using IN with escaped quotes: {label/city} IN (\"Vancouver\",\"Halifax\”). Please let me know if this helps.
Open in Slack
PreviousNext
Powered by