Input Control visualization #13314

nreese · 2017-08-03T13:53:45Z

Adds visualization type for creating input panels for dashboards.

Range slider input. Slider min and max obtained via a min/max aggregation call when panel is first rendered.
Options list input. Options are loaded via a terms aggregation call when panel is first rendered.

Replaces experimental PRs #11873 and #12126

nreese · 2017-08-31T01:26:38Z

jenkins, test this

nreese · 2017-09-01T11:57:14Z

jenkins, test this

stacey-gammon

Sending out first round of comments.

stacey-gammon · 2017-09-05T13:21:08Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ }
+
+ handleToggleControlVisibility() {
+ this.setState({


Should be:

this.setState(prevState => { isEditorVisible: !prevState.isEditorVisible });

See https://github.com/elastic/kibana/blob/master/style_guides/react_style_guide.md#when-a-state-change-involves-the-previous-state-or-props-pass-setstate-a-function-instead-of-an-object

stacey-gammon · 2017-09-05T14:05:15Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ }
+
+ return (
+ <div className="sidebar-item">


What do you think about breaking this component down into something like EditorSummaryBar and EditorDetails? Might help pare this back a little bit, and neither of those components would need any state.

Not sure this gets you anything. With the above requested changes, control_editor is very straightforward.

stacey-gammon · 2017-09-05T14:09:45Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ render() {
+ let editor;
+ if (this.state.isEditorVisible) {
+ editor = (


What do you think about either making this a function outside render, or a separate component? e.g. getEditorContents() and then below could do

{ this.state.isEditorVisible && getEditorContents() }

stacey-gammon · 2017-09-05T14:10:46Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ super(props);
+
+ this.state = {
+ isEditorVisible: true


What do you think about isEditorCollapsed?

stacey-gammon · 2017-09-05T14:11:52Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ <input
+ className="kuiTextInput"
+ type="text"
+ value={this.props.controlParams.label}


These should all have spaces inside the parens (and elsewhere in the file)

value={ this.props.controlParams.label }

Are you sure about that? From working in x-pack-kibana I know that from 6.1 onward there is an eslint rule enforcing no spaces inside of {}.
https://github.com/elastic/kibana/blob/master/packages/eslint-config-kibana/.eslintrc.js#L89-L100

Whoa you are right (https://github.com/elastic/x-pack-kibana/pull/2371 and #13323 did all the conversions), sorry for the misdirection @nreese and thanks for pointing that out @archanid. Looks like we switched it over to match the AirBnb style guide. I guess the react style guide should be updated because all of the examples in there use the old style of spaces inside.

I filed #13846 to keep track.

stacey-gammon · 2017-09-05T14:28:32Z

src/core_plugins/input_control_vis/public/components/editor/index_pattern_select.js

+ constructor(props) {
+ super(props);
+
+ this.loadOptions = this.loadOptions.bind(this);


This is fine, but just wanted to point out there is another way to do this that is even more concise:

https://github.com/elastic/kibana/blob/master/style_guides/react_style_guide.md#avoid-creating-a-function-and-passing-that-as-a-property-in-render-functions

stacey-gammon · 2017-09-05T14:37:56Z

src/core_plugins/input_control_vis/public/components/editor/index_pattern_select.js

+import React, { Component } from 'react';
+import Select from 'react-select';
+
+export class IndexPatternSelect extends Component {


TSVB has a similar Index pattern field, except that it's not a drop down and can accept any index pattern on the fly. Unless there is a specific reason for the differences, I think we should try to do the same - either let them enter in any custom index pattern here, or adjust TSVB to be a drop down like this. @simianhacker or @snide -- any thoughts on this?

I was going to suggest this go into the uiFramework but because of the K7 stuff in progress, it might not be worth it right now. Just when K7 gets here, we'll want to migrate over to use those control components.

TSVB will probably always be adhoc because there are a lot of users with dashboards that depend on the current behavior; I don't want to take that away from them.

stacey-gammon · 2017-09-05T14:47:21Z

src/core_plugins/input_control_vis/public/components/editor/index_pattern_select.js

+import React, { Component } from 'react';
+import Select from 'react-select';
+
+export class IndexPatternSelect extends Component {


I think this can be a functional, stateless component: https://github.com/elastic/kibana/blob/master/style_guides/react_style_guide.md#prefer-stateless-functional-components-where-possible

stacey-gammon · 2017-09-05T15:02:09Z

src/core_plugins/input_control_vis/public/components/editor/field_select.js

+import React, { Component } from 'react';
+import Select from 'react-select';
+
+export class FieldSelect extends Component {


This component looks like it could be generalized for the uiFramework as well - e.g. FilterableSelect.

@snide - what's your take on components like this. Would you prefer they get moved into the uiFramework ala k6, or should we hold off for now due to incoming k7?

stacey-gammon · 2017-09-05T15:03:21Z

src/core_plugins/input_control_vis/public/components/editor/list_control_editor.js

+import { IndexPatternSelect } from './index_pattern_select';
+import { FieldSelect } from './field_select';
+
+export class ListControlEditor extends Component {


Make stateless function. I thought we had eslint checks for this recently put it place, but maybe it's only turned on in the uiFramework... CJ would know but I don't want to tag him on paternity leave.

Few other files/components I see that should be in the functional stateless variety.

stacey-gammon · 2017-09-05T15:09:56Z

One more thing - can you add jest tests for all the react components?

timroes · 2017-09-06T17:12:45Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ Label
+ </label>
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <input


Please label this input with the above label (see accessibility style guide) using htmlFor in React.

timroes · 2017-09-06T17:13:30Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ {this.props.controlTitle}
+ </span>
+ <div className="vis-editor-agg-header-controls kuiButtonGroup kuiButtonGroup--united">
+ <button


This button is missing an aria-label, that describes it (since it doesn't have any textual content).

timroes · 2017-09-06T17:13:37Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ >
+ <i aria-hidden="true" className="fa fa-chevron-down" />
+ </button>
+ <button


This button is missing an aria-label, that describes it (since it doesn't have any textual content).

timroes · 2017-09-06T17:14:40Z

src/core_plugins/input_control_vis/public/components/editor/field_select.js

+ Field
+ </label>
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <Select


Please label this Select (you can set an id with inputProps={{ id: 'yourId' }}) with the above label.

timroes · 2017-09-06T17:15:08Z

src/core_plugins/input_control_vis/public/components/editor/index_pattern_select.js

+ Index Pattern
+ </label>
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <Select.Async


Please label this Select (see other comment).

timroes · 2017-09-06T17:15:47Z

src/core_plugins/input_control_vis/public/components/editor/list_control_editor.js

+ Size
+ </label>
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <input


Please label this input with the above label (see other comment).

timroes · 2017-09-06T17:16:03Z

src/core_plugins/input_control_vis/public/components/editor/range_control_editor.js

+ Step Size
+ </label>
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <input


Please label this input with the above label (see other comment).

timroes · 2017-09-06T17:17:40Z

src/core_plugins/input_control_vis/public/components/editor/vis_editor.js

+
+ <div className="kuiSideBarFormRow">
+ <div className="kuiSideBarFormRow__control kuiFieldGroupSection--wide">
+ <select


Please provide a label (e.g. via aria-label) for this select.

timroes · 2017-09-06T17:18:28Z

src/core_plugins/input_control_vis/public/components/vis/list_control.js

+ <FormRow
+ label={this.props.control.label}
+ >
+ <Select


Please label this Select (see other comment).

timroes · 2017-09-06T17:24:38Z

src/core_plugins/input_control_vis/public/components/vis/range_control.js

+ label={this.props.control.label}
+ >
+ <div className="inputRangeContainer">
+ <InputRange


Please label this element, using aria-labelledby on the InputRange and set this to the id of the label in FormRow (I guess that needs some modifications.

kobelb

I have general hesitations to us adding another method of selecting/specifying an index-pattern with this visualization. We have the "traditional" method, and the TSVB free-form method, the Timelion method, and now this.

I'm wondering if this is intertwined with us defining a bunch of different input controls for a dashboard as a single visualization. I'd be interested to see how these are used/re-used because there's potential for each input control being it's own visualizations allowing us to utilize the existing Visualize workflow of selecting an index-pattern/etc. while allowing more re-use opportunities.

I'm in no way an authority on this design decision, but would be interested to hear others thoughts.

kobelb · 2017-09-05T13:42:29Z

src/core_plugins/input_control_vis/public/components/vis/range_control.js

+import InputRange from 'react-input-range';
+import { FormRow } from './form_row';
+
+export class RangeControl extends Component {


I'm not finding the way the RangeControl works to be very intuitive. When it's first displayed and not being used for filtering, the start/end "dots" are on top of each other:

even though it's effective showing all values within the min-max and the following feels more natural:

Additionally, once the range slider has been moved from the starting position, it can't be put back there and stops at the first "step":

It's also impossible to move the Range slider to the max-value unless it's a multiple of the step:

The min-max labels are also occasionally cut-off for large values:

kobelb · 2017-09-07T19:51:22Z

src/core_plugins/input_control_vis/public/components/editor/index_pattern_select.js

+ this.loadOptions = this.loadOptions.bind(this);
+ }
+
+ loadOptions(input, callback) {


Since the IndexPatternSelect itself is loading the index-patterns, every-time that we add a new "input control" we're making another network request to retrieve the list of index patterns. Can we at least cache this for reuse so it only happens once?

I was thinking of changing this to limit the index-pattern search to 100 results. Then I would configure Select.Async to fire the search every time a character is added to the filter. This is how the dashboard add 'Visualzation' and 'Saved Search' function. What do you think?

kobelb · 2017-09-07T19:52:19Z

src/core_plugins/input_control_vis/public/components/editor/field_select.js

+ }
+
+ async loadFields(indexPatternId) {
+ if (!indexPatternId || indexPatternId.length === 0) {


loadFields is called by the constructor and whenever the indexPattern changes, potentially leading to a race condition if there's any type of inconsistent network latency.

kobelb · 2017-09-07T20:05:53Z

src/core_plugins/input_control_vis/index.js

@@ -0,0 +1,9 @@
+export default function (kibana) {


I feel like this should be split into two tabs, with only the "Update kibana filters on each change" being on the "Options" tab and everything else being on the first tab. Personally, I find "Update kibana filters on each change" being enabled by default to be a much more pleasant UX and wonder if this should be the default.

Great idea. I have split the editor into two tabs; Controls and Options

The idea behind disabling "Update kibana filters on each change" by default is that only submitting all of the filters at a single instant puts the least amount of stress on the cluster. The default is designed for the usecase where the Panel contains many controls. Users can fiddle with several filters and then apply them all at once - so the dashboard only has to update 1 time instead of each time a control is modified.

kobelb · 2017-09-08T11:39:07Z

...ore_plugins/input_control_vis/public/components/editor/__snapshots__/vis_editor.test.js.snap

@@ -0,0 +1,592 @@
+// Jest Snapshot v1, https://goo.gl/fbAQLP
+
+exports[`renders InputControlVisEditor 1`] = `


The way we're doing these snapshots feel like they're going to break all the time. They're testing the implementation details of all nested components, including the Kui framework, so anytime these change we'll have to update the snapshot. Have we considered using enzyme to do shallow rendering for the snapshot tests?

kobelb · 2017-09-08T11:43:30Z

src/core_plugins/input_control_vis/public/components/vis/__snapshots__/vis.test.js.snap

@@ -0,0 +1,413 @@
+// Jest Snapshot v1, https://goo.gl/fbAQLP


Same concerns as above.

kobelb · 2017-09-08T11:47:23Z

src/core_plugins/input_control_vis/public/components/vis/vis.js

+ renderControls() {
+ return this.props.controls.map((control, index) => {
+ let controlComponent = null;
+ switch (control.type) {


Can we add a default for this switch that throws an Error? This could lead to some hard to understand bugs.

kobelb · 2017-09-08T11:56:34Z

src/core_plugins/input_control_vis/public/vis_controller.js

+ if (status.params) {
+ this.initControls();
+ }
+ return new Promise(() => {});


Why are we returning a Promise that never resolves? This is making the render-counter attribute always stay at 0, which will cause issues with Reporting.

kobelb · 2017-09-08T12:02:02Z

src/core_plugins/input_control_vis/public/vis_controller.js

+ initControls() {
+ this.controls = [];
+
+ controlFactory(


I'm thinking that if we change the controlFactory to deal with a single control, then we could switch from using a callback below for each individual control and use a Promise which seems more natural.

This would also allow us to use a Promise.all for each of the controlFactory to use with the render method.

I did it this way so that a single _msearch would be used to init all controls in a panel. The weirdness comes from the fact that fetch.these uses the defer promise pattern

kobelb · 2017-09-08T12:08:15Z

src/core_plugins/kibana/public/dashboard/styles/index.less

@@ -112,6 +112,10 @@ dashboard-grid {
 i.remove {
 cursor: pointer;
 }
+
+ .gs-w {
+ z-index: auto;


Is something else setting this to something besides auto? auto should be the default z-index for elements.

Gridster sets this to 1 for each grid. This caused problems with overflow of the list select and needed to be set to auto

kobelb

LGTM

timroes · 2017-09-11T11:42:34Z

Unfortunately I think we still need some refactoring with the ids. Ids in HTML need to be unique on the whole page, meaning you cannot assign a static id in a component (like the editor components) that might get rendered multiple times.

You can use the htmlIdGenerator service from the ui_framework, to generate ids. I just merged this onto master (and 6.x) so you would need to rebase on master again.

I explained how to use this service, in the accessibility styleguide.

nreese · 2017-09-11T20:06:02Z

@stacey-gammon I have added all of the requested jest tests and should have addressed all of your comments if you want to take another look.

@timroes I have fixed all of the html elements with id collisions.

kimjoar · 2017-09-11T22:22:43Z

src/core_plugins/input_control_vis/public/components/editor/control_editor.js

+ this.state = {
+ isEditorCollapsed: true
+ };
+ }


When just setting the initial state, the constructor isn't needed:

export class ControlEditor extends Component { state = { isEditorCollapsed: true }

kimjoar · 2017-09-11T22:27:49Z

src/core_plugins/input_control_vis/public/components/editor/range_control_editor.js

+import { FieldSelect } from './field_select';
+
+function filterField(field) {
+ return ['number'].includes(field.type);


Can be simplified to

return field.type === 'number'

stacey-gammon · 2017-09-12T13:14:19Z

When I tried to create my first input control, the default tab is Options, not Controls. Is that intentional? I think it's a little confusing because all I see is a check box then and not much else to show me how to start setting it up.

How difficult would it be to adjust the indexPattern drop down from allowing any dynamic index pattern, like TSVB? I like the control here better in that it auto completes with your current patterns, but it might be nice to allow free form, if desired - as long as there isn't a technical reason not to. Then that will match what TSVB does.

stacey-gammon · 2017-09-12T13:19:06Z

I think I notice a bug with the index pattern drop down.

Enter in a character that doesn't match any index pattern, e.g. '*'

- Click outside of the control which will clear the contents:

- Press the drop down icon to see the possible index patterns, and nothing shows up.

If you go back and add in another character, then explicitly delete it (not just clicking away), it will clear the value, and the next time you click the drop down icon, you'll see the expected patterns:

stacey-gammon · 2017-09-12T13:20:50Z

From a design standpoint, I think there should be padding above these controls:

nreese · 2017-09-15T14:45:56Z

@stacey-gammon @snide @kobelb What do you think about @JacobBrandt's idea of ditching react-input-range and just using 2 native range inputs? The latest commit changes the range control to provide a very rough implementation showing how @JacobBrandt's request would function. Is this better, worse, or just different? Is this worth pursuing further? I can polish this up if this seems like a better control mechanism.

kobelb · 2017-09-15T16:18:21Z

@nreese to be completely honest, I don't find it to be intuitive at all...

JacobBrandt · 2017-09-15T19:12:59Z

@nreese Now that I see it I can see what @kobelb is saying. Maybe try putting the two input fields side by side in the middle.

<-------*----> 7105 to 8771 <---*-------->

Another option is to keep react-input-range and put the input fields at the beginning or end of the slider

<------*-------------------*--> 7105 to 8711

You'll still run into issues where the dots are on top of each other but with the input fields you'll at least be able to see the values you can't read on the slider.

snide · 2017-09-15T20:15:35Z

JacobBrandt · 2017-09-15T20:55:34Z

@snide Yea that's better if we're going to keep the one slider approach.

stacey-gammon · 2017-09-18T13:18:13Z

I like the single slider better too. ++ to @snide's suggestion.

This reverts commit aed599e.

…urce.fetch

nreese · 2017-09-18T16:03:14Z

@stacey-gammon Thanks for all the great feedback. Below are responses. I tried to summarize here instead of answering each individually. Would you mind taking another look at the PR?

Options tab opened by default: Great point, I have changed so that the Controls tab is now the default tab when the editor is opened.
Adjust the indexPattern drop down from allowing any dynamic index pattern: This is not possible. The control must target a single index pattern.
Bug with the index pattern drop down where enter a character that doesn't match any index pattern, click outside of the control, and finally press the drop down icon to see the possible index patterns, and nothing shows up: This is a bug with react-select and will need to be fixed upstream. I will create a PR for react-select and get this fixed.
Padding above the control buttons: Padding has been added
The difference between Clear and Cancel isn't very clear: Changed buttons to Apply Changes, Cancel Changes, and Clear Form. Modified how Clear Form works so that instead of clearing kibana filters, it just clears the form and Apply Changes still has to be clicked to clear the kibana filters.
delay when pressing Clear: There is no more delay when Clear Form is clicked.
Unable to select certain options in list control drop down: Good find - there was a bug where numeric values or string values containing a comma were un-selectable. That has been resolved.
input controls can also extend the borders of the dashboard panels: Unresolved and tracked by issue Panel overflows #13982

nreese · 2017-09-18T16:05:03Z

@JacobBrandt I have updated the range control to include inputs for setting the value more precisely. Try it out and see if this makes sense

stacey-gammon · 2017-09-18T19:38:32Z

Awesome, the new buttons and labels are way more intuitive. One little UX oddity, but does not need to be addressed in this PR:

JacobBrandt · 2017-09-19T00:01:58Z

@nreese Yep. This makes sense and will work well, thanks!

nreese · 2017-09-19T13:38:59Z

@timroes Everything should be good to go. Can you take another look?

Fixed the a11y issues

* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control

nreese · 2017-09-20T13:47:16Z

backported to 6.x #14074

jccq · 2017-10-07T07:57:26Z

my2c., making this work on top of a saved search instead (or additionally to ) an index pattern could also be useful (Future version?)

nreese · 2017-10-07T12:44:06Z

@jccq interesting idea, added to feature request meta issue #13911

* react editor example * ensure props are not updated * use new stageEditorParams method to stage parameter changes * make component stateless * use terms_vis_editor component * get add button to work * update vis controller to display terms input controls * update componenent when query bar updates * add functional test * lay ground work for different control types in single visulization * make editors for range and text controls * text control * implement type ahead suggestor for text control * add range slider * some CSS work * add submit button, move control init functionallity under control_factory * add custom options for control types * provide buttons to move controls up and down * Make ControlEditor component and clean up styling of editor * styling work * multi select for terms dropdown control * add option to disable filter staging, only enable submit button when filters are staged * clean up range styling * rename top level vis folder * cleanup * move control type select out of each control editor * dark theme styling * use ui/public/filter_manager/lib/phrases.js to build phrases filter, add tests to range filter manager * use savedObjectsClient to get index patterns * remove text control and add id to controls for react tracking * ensure fields get updated when index pattern changes * update PropTypes for react 15.6.1 * update to latest react-select to avoid isMounted deprecation warnings * fix input controls functional test * rename termsControl to listControl to be more generic * add function test for clear button, refactor directory structure * functional tests for updateFiltersOnChange is true * fix react-select clipping problem in dashboard * try clicking option instead of pressing enter to set react-select value in functional tests * react-select css * clean up control_editor component, make ListControlEditor component be function * add jest test for vis_editor component and accessibility * add decimal places option to range slider * add jest test for InputControlVis component * add default to switch blocks, split editor into seperate tabs, use shallow in snapshot tests * fix race condition in field_select, update index_pattern_select to fetch indexPatterns on each filter * clean up control initialization * use htmlIdGenerator to avoid html element id conflicts * update functional test to support new editor tabs * finish jest tests for sub componenets * mark vis as experimental, refactor buttons for better usability * fix bug in list control where unable to select options containing numbers and options containing commas. Truncate display of long list options * fix chart types functional test * fix jest tests, add margin to action buttons * remove binds from render functions * experement with native input range sliders * Revert "experement with native input range sliders" This reverts commit aed599e. * Use Promise.resolve in tests and replace _createRequest with searchSource.fetch * add inputs to range control

stbka · 2018-04-27T12:20:01Z

There should be an option to enable drop down fields depending on each other.

When you choose a value in the first field there should only be those values showed up in the second that are existing in the index in combination with the first value. And vice versa.

alexfrancoeur mentioned this pull request Aug 7, 2017

Terms Dashboard Control #11935

Closed

nreese force-pushed the inputPanel branch from 3a244f7 to 39397e9 Compare August 10, 2017 14:23

nreese force-pushed the inputPanel branch from 8226706 to ccc15d0 Compare August 17, 2017 17:14

nreese force-pushed the inputPanel branch 3 times, most recently from bf5a80b to 0586962 Compare August 29, 2017 19:25

nreese force-pushed the inputPanel branch from 396d352 to db38dc0 Compare August 31, 2017 16:33

nreese added v6.1.0 v7.0.0 :Sharing release_note:enhancement labels Aug 31, 2017

nreese changed the title ~~[WIP] Input panel~~ Input Control visualization Aug 31, 2017

nreese requested review from kobelb and stacey-gammon August 31, 2017 17:50

stacey-gammon suggested changes Sep 5, 2017

View reviewed changes

timroes previously requested changes Sep 6, 2017

View reviewed changes

kobelb reviewed Sep 8, 2017

View reviewed changes

nreese mentioned this pull request Sep 8, 2017

[Meta] Input controls enhancements #13911

Closed

5 tasks

kobelb approved these changes Sep 11, 2017

View reviewed changes

nreese force-pushed the inputPanel branch from e36c4db to b099c90 Compare September 11, 2017 16:35

kimjoar reviewed Sep 11, 2017

View reviewed changes

nreese added 3 commits September 18, 2017 07:40

Revert "experement with native input range sliders"

7328088

This reverts commit aed599e.

Use Promise.resolve in tests and replace _createRequest with searchSo…

484bc5a

…urce.fetch

add inputs to range control

912d3be

stacey-gammon approved these changes Sep 18, 2017

View reviewed changes

nreese merged commit 30cc42f into elastic:master Sep 20, 2017

nreese mentioned this pull request Sep 20, 2017

[6.x]Input Control visualization #14074

Merged

jccq mentioned this pull request Oct 7, 2017

Consider as general Kibana enhancement nreese/kibana-time-plugin#25

Closed

rashidkpc mentioned this pull request Dec 4, 2017

[Meta] Input panels #6884

Closed

5 tasks

nreese deleted the inputPanel branch February 13, 2018 19:33

aphelionz mentioned this pull request Jun 12, 2018

Accessibility: Kibana 6.3 Meta Issue #18866

Closed

48 tasks

		@@ -0,0 +1,592 @@
		// Jest Snapshot v1, https://goo.gl/fbAQLP

		exports[`renders InputControlVisEditor 1`] = `

Input Control visualization #13314

Input Control visualization #13314

Conversation

nreese commented Aug 3, 2017 • edited Loading

nreese commented Aug 31, 2017

nreese commented Sep 1, 2017

stacey-gammon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stacey-gammon commented Sep 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kobelb left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nreese Sep 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kobelb left a comment

Choose a reason for hiding this comment

timroes commented Sep 11, 2017

nreese commented Sep 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stacey-gammon commented Sep 12, 2017

stacey-gammon commented Sep 12, 2017

stacey-gammon commented Sep 12, 2017

nreese commented Sep 15, 2017

kobelb commented Sep 15, 2017

JacobBrandt commented Sep 15, 2017 • edited Loading

snide commented Sep 15, 2017

JacobBrandt commented Sep 15, 2017

stacey-gammon commented Sep 18, 2017

nreese commented Sep 18, 2017

nreese commented Sep 18, 2017

stacey-gammon commented Sep 18, 2017

JacobBrandt commented Sep 19, 2017

nreese commented Sep 19, 2017

nreese commented Sep 20, 2017

jccq commented Oct 7, 2017

nreese commented Oct 7, 2017

stbka commented Apr 27, 2018

nreese commented Aug 3, 2017 •

edited

Loading

nreese Sep 8, 2017 •

edited

Loading

JacobBrandt commented Sep 15, 2017 •

edited

Loading