Hi Team, I’m attempting to pass dynamic filters to dashboards using

filterContextRef

referring to the documentation Dashboard Props To understand how it works, I’m starting with a constant filter value to verify its functionality. To achieve this, I examined the API requests made when filters are applied after opening the dashboard. The relevant URL for the API request is:

https://{env}.cloud.gooddata.com/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute

for which the payload was as follows

{
  "resultSpec": {
    "dimensions": [
      {
        "localIdentifier": "dim_0",
        "itemIdentifiers": [
          "measureGroup"
        ]
      }
    ],
    "totals": []
  },
  "execution": {
    "measures": [
      {
        "localIdentifier": "m_c_gwp_100_sum",
        "definition": {
          "measure": {
            "item": {
              "identifier": {
                "id": "c_gwp_100",
                "type": "fact"
              }
            },
            "aggregation": "SUM"
          }
        }
      }
    ],
    "attributes": [],
    "filters": [
      {
        "positiveAttributeFilter": {
          "label": {
            "identifier": {
              "id": "org_id",
              "type": "label"
            }
          },
          "in": {
            "values": [
              "ABC"
            ]
          }
        }
      }
    ],
    "auxMeasures": []
  },
  "settings": {}
}

I tried to replicate this and create a filter context and passed it to embedded dashboard

const orgFilter = newPositiveAttributeFilter(
    idRef("org_id", "label"),  // matches the id from JSON
    ["ABC - XYZ"]
  );

  const filterContext = {
    filtersByIdentifier: {
      orgFilter: orgFilter
    }
  };

<Dashboard
    config={{ initialRenderMode: 'view', isReadOnly: true }}
    dashboard={props.dashboardId}
    filterContextRef={filterContext}
/>

But it doesn't work, and I get the

Unexpected URI: "undefined"

in the dashboard page. I don't see any failed APIs in the network tab. Is this the correct approach, or is there a better way to achieve this?

Hi Vikraman, May I ask what SDK version are you using?

Hi Julius, Its 10.4.0 actually

Hi there Vikraman, Radek from the Technical Support team here 🙂 There's a slight catch with this one - the API format is not always the same as what frontend uses (and vice-versa). When working with the SDK, it's best to use Dashboard dispatch commands. We have some pretty detailed examples of filters and filter changes available here: https://gdui-examples.herokuapp.com/dashboard/dispatch-dashboard-command-hook Hope the practical examples are helpful!

Hi Radek, Thank you for sharing this. I will review it and determine how it needs to be implemented.

Hi there! I'm looking into this as we speak 🙂 You're right that the dispatch commands rely on the Dashboard already having loaded, I'm trying to dig out a better way to address your use-case (and also answer your questions).

Thanks for the quick response! Please keep us informed if there are any updates.

Okay, so one step forward - turns out dispatch commands are indeed the best way, at least in my opinion. The difficulty with the

filterContextRef

is that this needs a URI to the filter definition existing on the backend - as such, you would have to implement logic where the filters in your app are sent to our REST API, and the resulting URI is then used as the reference to load the Dashboard. On the other hand, dispatch commands are also used in our own filter loading on the website - it is implemented through events/actions. Essentially, we listen to dashboard init and dispatch action to set the filter state. Next up, for

Md.RestaurantCategory

- this is a reference to an attribute existing in the local metadata catalog; the catalog is exported via a tool we provide, and it essentially provides a handy way to reference your metadata objects (attributes, metrics and so on) in code! If you execute the export tool, you will end up with a file like

catalog.ts

in the

src

folder - importing this in your script allows you to refer to your objects easier. As far as

/gdc/md/

paths go, this is the GD Platform API - for GD Cloud, the equivalent is

/api/v1/entities/workspaces/{workspaceId}/attributes/{objectId}

(or replace with "metrics" for metrics 🙂). Similarly, if you want to get all attributes/metrics, you can just leave out the objectId! This would be the preferred way of getting your list of IDs if you decided not to use the metadata catalog export instead. I know I kind of aggregated the list into a free-flow answer, but I think this about covered all that should be helpful to the implementation/relevant to GD Cloud! 🙂

Thank you for the guidance provided earlier. Following the instructions, we successfully generated the metadata catalog and attempted to dispatch commands during the dashboard initialization event. We referred to the example URI you shared earlier:

uris: ["/gdc/md/xms7ga4tf3g3nzucd8380o2bev8oeknp/obj/2196/elements?id=1"]

We are currently trying to construct a similar URI for our use case. However, we are unsure about what

2196

and

id=1

represent in this context. When we used the endpoint:

/api/v1/entities/workspaces/{workspaceId}/attributes/{objectId}

we couldn’t identify the corresponding values for

2196

in the API response. Could you please provide more clarity on the meaning of

2196

and

id=1

? If there’s any relevant documentation or additional examples available, we would greatly appreciate it if you could share them. Thank you for your assistance.

I'm glad to see we're moving forward! To be honest, the documentation on details of filtering is a little sparse in this aspect - I think the best way to try and look closer is checking the dev console when making dashboard and filter changes (Saved Views are great here since they refer directly to filter loadouts). However, to point you in the right direction a little more, Cloud doesn't do IDs the same way as the Platform used to - now the IDs are string values (for example, "Customer city" might have an id of "customer_city")! 🙂

Hi @Radek Novacek, We fixed this but writing javascript code that modifies the filters after the the report gets generated Instead of passing it through the gooddata component as parameter as that above approaches were time consuming.