## Summary
When we switched to use `Combobox` we were no longer able to add custom
values for our dropdowns, and this prevented users from using regexp
values for `group`, `host`, `proxy` etc. This PR adds
`createCustomValue` flag so that any custom value can be entered into
the dropdowns.
## Detailed summary
- Make use of `Combobox`'s `createCustomValues` so that wherever
necessary, users are able to enter regex values.
<img width="720" height="221" alt="Screenshot 2026-01-05 at 7 15 23 AM"
src="https://github.com/user-attachments/assets/841716eb-cd86-49d1-b13c-a0e37e8a37b9"
/>
## Why
For users to be able to use regexp, and any custom value in our
dropdowns.
## How to test
For all query types where dropdowns are used and user configurable (i.e.
group, host, proxy, application) start typing a value that does not
already exist in the dropdown. You should see an option to `Use custom
value`
Fixes
[comment](https://github.com/grafana/grafana-zabbix/pull/2141#issuecomment-3698818476),
thanks for the testing and call out @christos-diamantis
## Sumary
When dealing with multiple hosts, it can be hard for customers filter
through and figure out which host to query metric data from. This PR
aims to make this easier by adding support for host tags so that there
is another layer of filtering / grouping applied for hosts.
## Detailed explanation
- Adds new UI components to allow adding one or more host tag filter,
and a switch to choose between `AND/OR` and `OR` operators when using
more than one filter following Zabbix's UI:
https://github.com/user-attachments/assets/c971f5eb-7e93-4238-bd6b-902cc657c014https://github.com/user-attachments/assets/5f8996de-684e-4ffa-b98e-8e205c4fc1df
- Modifies the existing `getHosts` function to make a call to the
backend with a few additional parameters to `extend` (essentially
extract) the host tags for a given selected group. No backend changes
were required for this.
## Why
To make it easier for customers to query metric data when dealing with
multiple hosts.
## How to test
- Go to explore or a dashboard and create a Zabbix query where the query
type is `Metrics`
- The easiest way to test is by selecting `/.*/` for Groups, checking
the returned `Hosts` they should all be there
- Add a host tag filter and change the keys and operators as well as
switching from `AND/OR` to `OR` you should see how the values returned
for `Host` changes
## Future work
Adding variable support for host tags once this is completed.
Fixes:
https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3609900134&issue=grafana%7Coss-big-tent-squad%7C126
and https://github.com/grafana/grafana-zabbix/issues/927
---------
Co-authored-by: ismail simsek <ismailsimsek09@gmail.com>
## Summary
With the new logic to merge backend and frontend query responses, some
of the frontend query responses were being lost due to early
termination.
Merging frontend and backend responses was not properly waiting for all
promises to resolve before returning this "merged" result
## Detailed explanation
In `mergeQueries` although `Promise.all` was triggered, we returned
immediately without waiting for the promises to actually resolve, now
instead of passing down promises:
- use `switchMap` so that the upstream backend response observable can
be used as an inner Observable value to be concatenated with the rest of
the responses
- Why not use `map`? To prevent out of sync results, we need to wait for
the promises to resolve **before** we pass it down to the `mergeQueries`
function, `map` does not allow that.
- use `from` and trigger `Promise.all` **before** calling `mergeQueries`
so that all promise results can be resolved and converted to observables
by the time they get passed into the function
- modify `mergeQueries` to accept `DataResponse` for arguments, clone
the existing data and return the merged result.
<img width="1700" height="398" alt="Screenshot 2025-12-29 at 1 06 05 PM"
src="https://github.com/user-attachments/assets/c07c59b1-43b8-47f9-adc6-67583b125856"
/>
## Why
To fix how frontend and backend queries are merged so that no response
gets lost in the process
## How to test
1. Create a new dashboard or go to Explore
2. For query type select `Problems` or anything that is not `Metrics`
3. Execute the query, and you should be able to see a response.
## Summary
Adds a non-intrusive warning banner in the query editor that alerts
users when the selected time range exceeds 1 year (365 days). This helps
users understand that their query may return a large amount of data and
could take longer to execute, without blocking or interrupting their
workflow.
Part of https://github.com/grafana/oss-big-tent-squad/issues/127
## Changes
- Added `TIME_RANGE_WARNING_THRESHOLD_DAYS` constant (365 days) in
`src/datasource/constants.ts`
- Created new `TimeRangeWarning` component in
`src/datasource/components/TimeRangeWarning.tsx`
- Integrated the warning component into the main `QueryEditor` component
## How it works
- When the dashboard time range is >= 365 days, a warning banner appears
at the top of the query editor
- The warning displays the formatted duration (e.g., "1 year and 30
days")
- The warning is purely informational - queries still execute normally
- Uses Grafana theme colors for consistent styling in both light and
dark modes
## Screenshot
The warning appears as a subtle banner with a warning icon:
<img width="705" height="374" alt="grafik"
src="https://github.com/user-attachments/assets/eb0ace4b-524a-488e-8f88-b7e9523660b0"
/>
## Why
Queries spanning years of data can return millions of data points and
potentially overload the Zabbix server. This proactive warning helps
users make informed decisions about their query scope without adding
friction to the normal query flow.
## Summary
Adds a non-intrusive warning banner in the query editor that alerts
users when their query matches a large number of items (>= 500). This
helps users understand that their query may return a large amount of
data and suggests using more specific filters.
Part of https://github.com/grafana/oss-big-tent-squad/issues/127
## Changes
- Added `ITEM_COUNT_WARNING_THRESHOLD` constant (500 items) in
`src/datasource/constants.ts`
- Created new `ItemCountWarning` component in
`src/datasource/components/ItemCountWarning.tsx`
- Updated `MetricsQueryEditor` to track and report the count of items
matching the current filter
- Integrated the warning component into the main `QueryEditor` component
## How it works
- When items are loaded for the dropdown in the Metrics query editor,
the component counts how many items match the current item filter
- If using a regex filter like `/.*/`, it applies the regex to count
matching items
- If the count is >= 500, a warning banner appears at the top of the
query editor
- The warning is purely informational - queries still execute normally
- The warning only appears for the "Metrics" query type
## Screenshot
The warning appears as a subtle banner with a warning icon:
> I set the limit as 5 just to show the warning
<img width="901" height="298" alt="grafik"
src="https://github.com/user-attachments/assets/a9be8563-1b90-4581-ad15-4e7035b4166e"
/>
## Why
Queries that match thousands of items via wildcard filters (e.g.,
`/.*/`) can return massive amounts of data and potentially overload the
Zabbix server. This proactive warning helps users make informed
decisions about their query scope without adding friction to the normal
query flow.
## Summary
Throughout Zabbix we did not have a uniform UI - some drop-down were
using `Select` others `Combobox` others a custom one that we created.
Some had placeholders and others did not. This PR aims to standardize
our Zabbix UI across our query, variable and config editors
## Detailed summary
- Migrate from `Select` to `Combobox` -> `Select` component is
deprecated
- Migrate from `HorizontalGroup` to `Stack` -> `HorizontalGroup` is also
deprecated
- Remove use of "custom" dropdown `MetricPickerMenu` in favor of
`Combobox` ensuring uniformity across our drop-down and removing
maintenance overhead for us down the line
- Standardize placeholders across all inputs
<img width="630" height="243" alt="Screenshot 2025-12-17 at 1 13 45 PM"
src="https://github.com/user-attachments/assets/9382057e-b443-4474-a9c8-850086d7f3d4"
/>
<img width="691" height="256" alt="Screenshot 2025-12-17 at 1 14 05 PM"
src="https://github.com/user-attachments/assets/a05ff2af-8603-4752-8d12-337dc381c0fd"
/>
## Why
To have a clean and standard UI and remove use of UI deprecated
packages.
## How to test
- Query Editor:
- By creating a new query in a dashboard or Explore and interacting with
all the different query types and drop-downs
- All drop-downs should be searchable and have placeholders
- Config Editor:
- By going to a datasource and ensuring that the dropdown for Datasource
(when DB connection is enabled) and Auth type are responsive and working
as expected)
Fixes:
https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3740545830&issue=grafana%7Coss-big-tent-squad%7C139
This PR migrates the use of `DatasourceApi` to `DatasourceWithBackend`,
with this a couple additional improvements were made:
1. Migrate to use `interpolateVariablesInQuery` everywhere instead of
the custom `replaceTemplateVariables` we were using
2. Moves util functions out of `datasource.ts` and into the existing
`utils.ts`
<img width="1261" height="406" alt="Screenshot 2025-11-20 at 11 37
56 AM"
src="https://github.com/user-attachments/assets/9e396cf2-eab0-49d1-958c-963a2e896eba"
/>
Now we can see the `query` calls being made to the backend:
<img width="367" height="102" alt="Screenshot 2025-11-20 at 11 38 18 AM"
src="https://github.com/user-attachments/assets/a5a9a337-7f19-4f7c-9d04-9d30c0216fb2"
/>
Tested:
- By running queries from Explore and Dashboards (with and without
variables)
- By interacting with all the different Editors to make sure `ComboBox`
was working as expected
Next:
Once this is merged, we will next be able to slowly move away from using
the `ZabbixConnector` to make backend datasource calls.
Fixes:
[#131](https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=139450234&issue=grafana%7Coss-big-tent-squad%7C131)
Updating react-table to v8.
- Migrating the existing table to v8
- Preserving the visuals and logic
What's done?
- Cell components are moved under `Cells` folder
- Old styles for react-table-6 is removed.
- Old types are removed
- All logic was preserved
- Some cell components are removed for simplicity
Fixes: https://github.com/grafana/oss-big-tent-squad/issues/125
This is a prerequisite for ugrading the react-table to v8.
- No logic change is introduced.
- Update DataSourceRef imports. The old import was deprecated.
This PR moves the health check to backend only leaving in the frontend
the functionality to test the dbconnector datasource.
Leaving the `dbconnector.testDataSource` should be fine since the
datasource types we allow for db connection with Zabbix already are
backend datasources, and so their health requests would go through the
backend.
Verified:
Clicking test and seeing a `health` request go out.
IMPORTANT: While testing this in the UI, I found a bug with the config
editor - whenever a change is made in the UI and tested, the changes
don't take effect (i.e. disabling trends, keeps `trends` set to `true`,
enabling db connection keep `dbConnectionEnabled` set to `false` and so
on.). Created a separate
[issue](https://github.com/orgs/grafana/projects/457/views/40?pane=issue&itemId=3627315751&issue=grafana%7Coss-big-tent-squad%7C132)
to fix this
Fixes https://github.com/grafana/oss-big-tent-squad/issues/124
Fixes https://github.com/grafana/grafana-zabbix/issues/2004
Zabbix 5.0.x supported filtering `Problems` feature with `applications`.
When this got removed, we removed the filter dropdown from the UI, but
failed to check whether applications were supported before sending out
the request with the parameters.
This was causing dashboards that had been created with zabbix version
`5.0.x` to fail when querying with newer versions of our plugin with
error: `Invalid params. Invalid parameter "/": unexpected parameter
"applicationids".`
These changes now ensure that we also check whether applications filter
should be supported before sending the backend request to fetch
problems.
How to test:
- use the attached JSON file. This was created using zabbix50 and
applying an `applicationids` filter for `Problems` query type OR
- run the `zabbix50` test environment:
```
cd devenv/zabbix50
docker-compose up -d
```
- create a dashboard that queries for `Problems` and filters with
applications then export the dashboard JSON
- stop the `zabbix50` test environment and start the `zabbix74` test
environment
```
docker-compose stop
cd ../zabbix74
docker-compose up -d
```
- import the dashboard you created above, it should load and work as
expected.
Bottom panel was created using zabbix50 and it used the application
filter. Both panels now load as expected:
<img width="2558" height="1018" alt="Screenshot 2025-10-21 at 2 28
25 PM"
src="https://github.com/user-attachments/assets/9613d59b-3f88-420c-9897-f8d988b3d2f0"
/>
Fixes https://github.com/grafana/grafana-zabbix/issues/1852
This PR resolves the below issues:
#2022#1465
Specifically, when executing a script on the problems panel, we do check
if the script scope is event or host.
Based on the script scope, the Zabbix API call is constructed
differently.
---------
Co-authored-by: Zoltán Bedi <zoltan.bedi@gmail.com>
This PR fixes an issue where the problems panel breaks when you change
to query type to `Triggers`.
How to reproduce:
1. Go to `Zabbix data source features` dashboard
2. Open Problems panel
3. Change`Query type` to `Triggers`
4. Select `Problems` from `Count by`
5. Change the `Group` to `Backend`
6. The problems panel should not error
---------
Co-authored-by: Zoltán Bedi <zoltan.bedi@gmail.com>
Changes:
- Use 10.4.8 as minimal supported Grafana version in plugins that
previously supported v9.
- Bump version to 5.0.0 as we are changing min supported Grafana version
