[Dashboard][Controls] Add Control Group Search Settings#128090
[Dashboard][Controls] Add Control Group Search Settings#128090ThomThomson merged 12 commits intoelastic:mainfrom
Conversation
…d query bar sync to the Control Group
…lGroupSearchSettings
…lGroupSearchSettings
|
@ThomThomson sent some suggestions for the flyout (PR). Mainly trying to make the three switches less prominent as right now they seem to stand out a lot more than the two fields above ( I would also like to suggest that we consider changing the wording of the |
…bana into controls/controlGroupSearchSettings
|
@andreadelrio design changes look great and have been merged into this PR. I also really appreciate the new copy idea for the I have implemented the new Copy, and am hoping that @KOTungseth likes it too when she does her copy review! |
…Style settings to labelPosition
@ThomThomson Awesome! to keep things consistent we should really rename |
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
jloleysens
left a comment
There was a problem hiding this comment.
AppServices changes LGTM!
There was a problem hiding this comment.
I was able to get in a situation where I couldn't unselect an option via the following steps:
1. Create two controls - for example, I didlastNameandgenderfor the E-Commerce sample data
2. Turn off hierarchical chaining
3. Make selections in both controls - for example, I chosegender = 'female'andlastName = 'McDonald'
4. Turn hierarchical chaining back on
5. In the situation above,McDonaldwas no longer a validfemaleselection so it doesn't appear in my list (can't even search it), but it's still showing as being selected
Once I unselectfemalewith hierarchical chaining on, I once again have access to unselectMcDonald- but this probably isn't ideal? Unsure how we should deal with that.
Ignore this 🙃 It was a matter of case sensitivity - I searched for mc and not Mc, which is why it wasn't showing up. Might be worth considering turning off case sensitivity in searches though?
Will continue to test and comment anything else I notice - so consider this a code review + a partial behavior review 👍
| width: ControlWidth; | ||
| } | ||
|
|
||
| export type ControlGroupChainingSystem = 'HIERARCHICAL' | 'NONE'; |
There was a problem hiding this comment.
Just a general style question for my own future reference - why did you choose ALL CAPS for these strings? Other constant strings, such as the different control widths/styles are all camel case (auto, oneLine, etc.), so I'm just curious about what differentiates this one.
There was a problem hiding this comment.
That's a good question! I chose all caps for these values because it was originally an enum, and I changed it to a union string type because they're better DX-wise.
I am not sure if we have a naming convention for union string types, but I have no strong feelings one way or another, and could quite easily change it! Let's figure out which casing is used more frequently and update accordingly.
src/plugins/controls/public/control_group/editor/control_group_editor.tsx
Show resolved
Hide resolved
src/plugins/controls/public/control_group/editor/control_group_editor.tsx
Show resolved
Hide resolved
| updateAllControlWidths(currentWidth); | ||
| } | ||
| applyChangesToInput(); | ||
| onClose(); |
There was a problem hiding this comment.
For specifically the onClose action - now that we have more settings and users could, in theory, lose their selections by accident, do we want to have a warning when the user cancels/clicks out of the control settings overlay like we do for adding a control? I could honestly argue both sides - pop up warnings are annoying, but are they more annoying than losing your selections? 😆 @andreadelrio thoughts?
There was a problem hiding this comment.
I am more on the side of a warning, as long as it only happens if the settings have changed from the initial settings. This feels to me like an enhancement we should log!
src/plugins/controls/public/control_group/embeddable/control_group_container.tsx
Show resolved
Hide resolved
src/plugins/dashboard/common/embeddable/dashboard_container_persistable_state.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
One bug I found when testing.
When I turn off hierarchical chaining, when there is more than one control, only the filter for the last control seems to be applied. It works fine if I just have a control on gender, for example - but as soon as I have gender and lastName, only the lastName control will actually be applied and the gender control is ignored. Here's a video of what I'm seeing:
2022-03-23_UnableToDeleteControls2.mp4
Heenawter
left a comment
There was a problem hiding this comment.
I have some confusion about what the Sync with query bar option does. Basically, assume I have a dashboard with the E-Commerce data where this option is fully turned off. I have a filter pill for gender = 'female' and I have a control for gender where male is selected. I assume this should show no data, but it doesn't? And this happens regardless of whether Validate user selections is true or not.
This is probably just my own misunderstanding, but some clarification would be appreciated 👍
|
Thanks for the super-thorough review Hannah! I will respond to your questions here:
|
Ahhh, that makes sense! Definitely think it's worth addressing this in the future, but seems like it's not worth it right away 👍
Perfect!! 😄 I'll approve once that is all fixed - I played around quite a bit with the settings, and wasn't able to find any other blockers and/or bugs.
Gotchya, gotchya. That makes a lot more sense, thanks - I felt like I was going crazy, hah 😄 |
src/plugins/dashboard/common/embeddable/dashboard_control_group.ts
Outdated
Show resolved
Hide resolved
💚 Build SucceededMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Saved Objects .kibana field count
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: |
Resolves #126811
Resolves #123879
Summary
This PR adds new settings to the control group, allowing configuration of:
Query settings: Query settings influence which pieces of state from the query bar are applied to the controls. Generally they should be all set to on or off, but there are advanced use cases where an author may want to ignore the timerange, filter pills, or the querry bar separately.
Validation: When Controls query for data, they also send a validation query to see if their selection would cover any documents. If the validation setting is off, these validation results are not used. If the setting is on, selections which are invalid are ignored.
Hierarchical chaining: With Hierarchical chining on, controls pass their filters from left to right. With Hierarchical chaining off, each control is independently filtered by the query bar settings, and are unrelated.
Tests
This PR also adds tests to ensure that each setting works properly. Additionally, the functional test suite has been split up into 4 files under a new folder in
dashboard_elementsChecklist
Delete any items that are not applicable to this PR.