[Research] Filters handling between dashboard, panels and data explorer

Problem Statement

We need to find a way to handle filters consistently between the data explorer, dashboard and GLQL-powered panels.

Current State

  1. Dashboards have their own filter system (datetime ranges, project selectors, etc.) that operate at the dashboard level ( see PJ guidelines gitlab-org/gitlab-services/design.gitlab.com!4940 (merged) )
  2. Panels within dashboards need to respect and apply these filters to their data queries. Panels can also override or refine dashboard filters with their own panel-level filters.
  3. Data Explorer operates independently with its own GLQL query interface
  4. Panels can be created directly from inside a dashboard or added from the data explorer

The Challenge

When integrating GLQL-powered panels into dashboards, we need a way to handle the following situations:

Example Scenario A

In a dashboard, we need to pass dashboard-level or panel-level filters (like date ranges, project selections) down to individual panels and use it appropriately into the GLQL query.

Consider a dashboard with two panels:

  • Panel A: Shows merged MRs
  • Panel B: Shows closed issues

Both panels should respect a dashboard-wide date filter, but apply it differently:

  • Panel A needs to filter by merged <= DATE
  • Panel B needs to filter by closed <= DATE

Example Scenario B

A GLQL query is added from outside a dashboard ( e.g from data explorer ), and the dashboard filters should be respected and injected into the query.

Example Scenario C

When exporting a GLQL query from a dashboard panel into any markdown content, the current filters should be applied.

Discussion Points

We need to explore solutions that address:

  • How should dashboard filters be communicated to panels GLQL queries?
  • How do external GLQL queries ( e.g. created from the data explorer ) could be added to a dashboard and its filters injected into the query?
  • When exporting a panel's GLQL query from a dashboard with filters, how do we maintain the currently used filters when the query is embedded outside the dashboard environment?

Potential Solution

a) Add support for variables in GLQL (#561707)

A possible solution would be to support variables in GLQL.

query: 
  project = $PROJECT and  type = MergeRequest and merged <= $MERGED_DATE
variables:
  MERGED_DATE = foo
  PROJECT: bar

where MERGED_DATE and PROJECT would then be set appropriately by the dashboard environment.

While technically that's doable, the question remain on how to structure the related UX

  • Each filter needs to have a variable associated with it.
  • When creating a new panel from a dashboard, it should be clear to the user which variables are available
  • How do we handle the case where a GLQL query is added from outside a dashboard (e.g. data explorer)? Does it get added without filters and the user is expected to modify the query so that filters are correctly applied?

Related discussions

Edited by 🤖 GitLab Bot 🤖