Hey there, in the JSON of a dashboard, it is possible to lock a filter by passing the following config to the dashboard content:

"attributeFilterConfigs": [
  {
    "localIdentifier": "my-filter",
    "mode": "readonly"
  }
],

Is there any way to provide a similar config to the whole workspace so all the dashboards share it by default?

Hey Bastien, Interesting question, but honestly, I am not quite sure if something like this is doable. May I know what exactly are you trying to achieve, please? Do you want to lock one particular filter across all Dashboards or would you like to lock all of your filters across all of your Dashboards?

Hello, we want to lock a specific filter (with a given localId) that exists in various filterContexts (it always have the same localId across the contexts), in all dashboards of a workspace preemptively (as in, creating a dashboard afterward through GD UI and embedding it with one of the custom filterContexts should use that config without having to alter the dashboard JSON through the API)

Hi Bastien, I am not sure if what you are describing is possible with the locked dashboard filters, but do I understand it correctly that your ultimate goal is to restrict all dashboards within a workspace to only show data filtered by one data column and do not allow your users to change it? If yes, then maybe the approach with Workspace Hierarchy and Workspace Data Filters could satisfy your needs. With this you can have a parent workspace which defines the data model, visualizations etc. and displays all the data and then its child workspaces where each of them can display only rows with defined value (i.e. clientID, Region, etc.). You can then assign different users to different workspaces and this way handle who can see what data. This (invisible) filter will works not only for all the dashboards, but also on all existing visualizations and all self service ad-hoc queries done by users. This is the recommended and supported way how to achieve data multi-tenancy within GoodData. Here is a tutorial how to set it up and how does it work.

Hey, thanks for the deep answer. Sadly I already took a look at workspace hierarchy for another reason, and while we may end up using it at some point, it can't be used for this particular thing: I'll try to sum it up succinctly: • in our App, we have "tenants" (ie: our customers), each with multiple users • each tenant can manage its own users (ie: create, delete, etc) • each user may have access to a set of "clusters" within the tenant (0-N) • for data security, we do have one GD user per tenant so they can't access other tenants data, but we do not want to replicate our whole user base in GD for various reasons, one of them being simplicity and avoiding having multiple source of truth since we would have to replicate user accesses into GD each time they're updated in our system by a end-user • initially we wanted to have one workspace per tenant for the same reason, we took a little look at workspace hierarchy, but due to the 0-N relations between users and clusters, it meant we needed one main workspace for the tenant then one workspace per clusters set combination (it can be anything from 10 users, each with their own clusters, to a user having 3 clusters, 2 of them being shared with another user) • due to how translations were initially handled in GD and our lack of experience with GD overall, we had to finally create one workspace per tenant per locale back then, meaning we currently handle "X tenants * Y supported locale" workspaces • now if we where to mix that with workspace hierarchy to handle cluster accesses, it would end in a literal combinatorial explosion • which leads to our current point: we do have a column for the clusters in our data, and that's why we're trying to use the filter that way

I see, thank you for the explanation. For the sake of completness, let me add that one additional level of data filtering available in GoodData are User Data Filters. But to use that to distinguish what individual users can see, you would need to have more than one user per tenant.