## 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 https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/4940 ) 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 * Initial problem identification: https://gitlab.com/gitlab-org/gitlab/-/issues/556730#note_2688415365