Kibana: Make time picker enable/disable more granular

[ycombinator]

Currently it is possible to enable or disable the time picker via the timefilter.enabled boolean flag. When set to true the time picker is displayed and when set to false the time picker is hidden in the UI.

The time picker is composed of two parts: a refresh interval selector and a time range selector. In some cases it is desirable to show the user the refresh interval selector but not show them a time range selector. Some examples of this might be:

• The pipeline viewer page in Logstash Monitoring (x-pack) where users are shown a version of the pipeline on the page. The version has a start time (when the version came into existence) and an end time (when the next version came into existence or now if this is the latest version). Navigating by version is more intuitive than navigating by time on this page.
• The Reporting Management page (x-pack) where we show users a list of reporting jobs. This is a current view of jobs but it still needs to be auto-refreshed so job statuses can be updated. Currently this refresh interval is configurable via kibana.yml but, with this proposal, could also be configured by individual users (if we decided that was a good idea).

It would be convenient to break up the show/hide toggle on the time picker into two separate show/hide toggles: one for the refresh interval selector (say, via a timefilter.refreshInterval.enabled flag) and one for the time range selector (say, via a timefilter.time.enabled flag). For backwards compatibility and convenience, we can preserve the current timefilter.enabled flag. There would be a logical AND relationship between these flags.

Since the time picker is so germane to Kibana I want to get broad consensus on this proposal before putting up a PR. 👍 if you are in favor of this enhancement, 👎 + comment if you have concerns or other ideas.

[timroes]

I like the approach in general. It could also solve some other "issues" we are currently having, like when being on discover enabling auto-refresh and then switching to an index pattern without a time field, the auto refresh is still stuck in the background, but cannot be disabled anymore. But I don't see a reason why a non time based index shouldn't be able to auto refresh. Just because the data itself isn't time based, doesn't mean there won't be new data, and you want a refresh.

[weltenwort]

Sounds good in general, but I'd like to add another consideration: We could implement this more fine-grained API as methods on the timefilter service to restrict the api, e.g. enableTimeFilter(), disableTimeFilter(), enableAutoRefresh(), disableAutoRefresh(). (the names are just examples)

One advantage would be that the API is more explicit than just setting a value on an object from various places scattered throughout the code (and hoping that nobody abuses the object to store other data). It would also be easy to pass these methods across module boundaries (React props, redux actions, new platform contracts).

[ycombinator]

@weltenwort I'm +1 for exposing the API via methods instead of properties for the reasons you mentioned. For backwards-compatibility reasons, however, we'll need to keep supporting the current timefilter.enabled property API.

[timroes]

If we keep the timefilter.enabled property, let's make it log a warning to console when setting it, that the timefilter.enabled property is deprecated and please use either of the above methods. So we can then remove it in 7.0.0, and every plugin author should have seen those warning already beforehand. Also we should fix our own usage of timefilter.enabled directly.

[epixa]

We don't need to deprecate plugin stuff. If we update our code to use the new functions and note the change in the release notes/blog, we can just remove the thing in a minor.