Add a predefined TimeRange filter if there is at least one DateTime* column

[slvrtrn]

Demo:

Screen.Recording.2023-02-23.at.00.16.05.mov

Full description:

There was a request from our users to restrict the query to the dashboard range automatically.

After some consideration, we decided to add a (removable) pre-defined filter that appears when we switch the tables if and only if we have at least one DateTime column. If we find some, the first DateTime column is picked, and we add the WithInGrafanaTimeRange filter automatically.

What is interesting about this filter is that the column selection there is restricted to DateTime (could be also *64 or Nullable) types only, so it is convenient to switch to another column if we failed to pick the right one, and the type of the filter is WithInGrafanaTimeRange by default.

If a user does not need this type of filter, they can delete it and just add another one.

I also added a convenience ClickHouse container to the docker-compose.yml.

[mshustov]

IMO the timerange filter should be applied by default without the necessity to introduce another UI element.
Ok, we ClickHouse doesn't have a convention for timestamp field for time series data, so we have to provide an option to select a field, but have sensible defaults for time-series data.

The default behavior of other datasources is to restrict timerange to the current value. For example, elasticsearch:
UI

query:

{"size":0,"query":{"bool":{"filter":[{"range":{"timestamp":{"gte":1677128427354,"lte":1677150027354,"format":"epoch_millis"}}}]}}

@bossinc what if we change the default query builder behavior to detect a first time/datetime field and apply WITHIN DASHBOARD TIME RANGE to it? The current implementation limited the filter value to WITHIN DASHBOARD TIME RANGE, which looks like a limitation for complex queries (with the combination of >, >=, OUTSIDE DASHBOARD TIME RANGE, etc.)

If you agree, could you point out the proper integration points?

[slvrtrn]

@mshustov, how do you select the DateTime column in that case?

[mshustov]

how do you select the DateTime column in that case?

I suggest providing a column selection and setting the value to WITHIN DASHBOARD TIME RANGE. The current implementation in the PR doesn't allow a user to change value from WITHIN DASHBOARD TIME RANGE.

[slvrtrn]

@mshustov

Now it is like this:

Screen.Recording.2023-02-23.at.17.20.16.mov

WDYT?

[mshustov]

@slvrtrn. Should the user have the ability to remove the filter? The current implementation doesn't support deletion.

[slvrtrn]

I simplified the logic now; the deletion bug should be gone.

[asimpson]

This is good!

I think I found one area where we have a user experience hole: removing all the filters. We should account for a user who removes the filters but then changes their mind.

[asimpson]

Nicely done! 🏆