Meta: Custom time ranges per panel

[stacey-gammon]

In order to complete implementation of #3578, we need to complete the following steps:

• EUI React Calendar supplied from design team
• In progress Dave EUI time range input control
• In progress Nathan Absolute/Relative/Now HOC time picker in Kibana, convert global time picker to use this new one.
• Done Stacey Improve embeddable communication layer - PR
• In Progress Stacey Clean up time range handling with embeddables - PR
  • Stacey Add time zone tests to ensure this PR doesn't break anything. Waiting on this PR to be merged first.
• In progress Stacey Refactor panel code in prep for pluggable panel actions

Mock:

cc @nreese @snide

[stacey-gammon]

@snide or @cchaos - can I get some design help for this?

Some initial ideas:

1. I think the date picker should be disabled when the toggle is on. Filed Allow superdatepicker to be disabled eui#2081

2. The save button is hidden under the pop up box which makes it a bit awkward to close, you have to click somewhere randomly

3. Ideas for making it obvious to the user that a time range override is being applied. I was thinking an icon on the header that has details in a tooltip on hover, but what then to do when the panel titles are hidden? Should it only show up on hover, or should something always be present?

[stacey-gammon]

Playground PR: #39937

[cchaos]

@stacey-gammon I can think in-depth on this next week (7/8)

[cchaos]

@stacey-gammon Here is a quick mock of a proposed design tweak to your solution.

[stacey-gammon]

hmm, it looks great, but I want to run through some options to implement those changes, or maybe take a shortcut on some of the functionality to minimize the time needed to implement.

In the ideal architecture, the embeddable panel wouldn't require knowledge about the customize panel time range action. This kind of separation would let us make per panel time range action an x-pack feature, as well as an example to other third party developers wanting to do something similar.

Ideally, we'd keep all the logic about the per panel time range inside the per panel time range plugin (or I actually put it in a big "advanced embeddable actions" plugin). To do that we would have to expose a way for plugins to hook into this badge area. We could actually do this using our current Triggers and actions registry without needing to introduce a new registry, which is great. The problem is in the custom label. The customize panel time range needs to store that label data somewhere so it persists. This is essentially phase 2 of embeddables.

Phase 2 of embeddables is a good amount of work and would push this from a 1 week to multi-week implementation time.

If we can get away without the custom label, I think we can do this much faster. When phase 2 comes around we can always consider the label. What do you think? Coule we use an icon and a tooltip to get around the length?

[cchaos]

To summarize, you're just saying that in terms of the mocks, you want to hold off only on allowing the time range custom label input? Was there anything else that can't be done in this first phase?

Ideally, you wouldn't want to hide the time-range under a tooltip. This would cause more motion by the user to find the time range and wouldn't work for static images (reports) or kiosk mode.

[stacey-gammon]

Yep that's right @cchaos - i just want to avoid the custom label since it adds a lot of complexity. I've already implemented everything else (though you may want to pretty up the "badge" styling). Otherwise just blocked on allowing the superdatepicker to be disabled and pretty printing the date:

• Allow superdatepicker to be disabled eui#2081
• Expose pretty print date range functionality eui#2118

[cchaos]

Thanks for clarifying.

I still don't think the toggle is necessary, however. All you need is the "Remove" button which should close the popover and reset the panel to use the global time picker.

As for the badge. All you need to use is <EuiBadge iconType="calendar">