[Controls] Add "Apply" button#174714
Conversation
c24a5e0 to
80d9080
Compare
b509f77 to
db8aa09
Compare
32536c4 to
c2cc71f
Compare
… src/core/server/integration_tests/ci_checks'
nickpeihl
left a comment
There was a problem hiding this comment.
Adding a few questions while I continue reviewing.
src/plugins/controls/common/control_group/control_group_persistence.ts
Outdated
Show resolved
Hide resolved
| <EuiFlexItem grow={false}> | ||
| <EuiButtonIcon | ||
| size="m" | ||
| disabled={!applyButtonEnabled} | ||
| iconSize="m" | ||
| display="fill" | ||
| color={'success'} | ||
| iconType={'check'} | ||
| data-test-subj="controlGroup--applyFiltersButton" | ||
| aria-label={ControlGroupStrings.management.getApplyButtonTitle( | ||
| applyButtonEnabled | ||
| )} | ||
| onClick={() => { | ||
| if (unpublishedFilters) controlGroup.publishFilters(unpublishedFilters); | ||
| }} | ||
| /> | ||
| </EuiFlexItem> |
There was a problem hiding this comment.
While I understand the issue with the tooltip bug, it's still not a great experience IMO. The Refresh button above shows a tooltip on hover so I kinda wish this button also showed the tooltip. That said, this is just a small annoyance to me and probably not worth holding up the PR.
apply-button.mp4
src/plugins/controls/public/control_group/component/control_group_component.tsx
Show resolved
Hide resolved
| }), | ||
| getPlayButtonDisabledTooltip: () => | ||
| i18n.translate('controls.timeSlider.playButtonTooltip.disabled', { | ||
| defaultMessage: 'Only applicable when auto-apply selections is enabled.', |
There was a problem hiding this comment.
This should probably align with the copy in the Control Settings. Maybe something like "Apply selections automatically" is disabled in Control Settings.
There was a problem hiding this comment.
I'm not convinced we even need this tooltip, as described in #174714 (comment).... Interested in what @andreadelrio and @amyjtechwriter think.
There was a problem hiding this comment.
There was a problem hiding this comment.
Are we allowed to remove the tooltip completely still? I'd vote for that option.
There was a problem hiding this comment.
@amyjtechwriter We've decided to keep the tooltip only in edit mode - so, with that in mind, does the copy sound okay to you?
| controlStyle: { type: 'keyword', index: false, doc_values: false }, | ||
| chainingSystem: { type: 'keyword', index: false, doc_values: false }, | ||
| panelsJSON: { type: 'text', index: false }, | ||
| showApplySelections: { type: 'boolean', index: false }, |
There was a problem hiding this comment.
I think (@jloleysens please keep me honest here 😅) ideally the dashboard.controlGroupInput mapping in packages/kbn-check-mappings-update-cli/current_mappings.json would be similar to the lens.state mapping. The data is still stored in _source but not in separate fields. However, we might need multiple modelVersions to achieve that.
e.g.
...
"dashboard": {
"properties": {
"controlGroupInput": {
"dynamic": false,
"properties": {}
},
...
But I wonder if we can keep the index: false, doc_values: false settings to unblock this PR and remove those fields in a separate PR later?
andreadelrio
left a comment
There was a problem hiding this comment.
Left you a comment about the disabled state.
…r/kibana into controls-apply-button_2023-01-3
|
@andreadelrio Addressed in #174714 (comment) and #174714 (comment) 🙇 |
src/plugins/dashboard/server/dashboard_saved_object/dashboard_saved_object.ts
Show resolved
Hide resolved
nickpeihl
left a comment
There was a problem hiding this comment.
lgtm! thanks for getting us closer to parity on input controls!
code review and tested controls and time slider controls with and without apply button
andreadelrio
left a comment
There was a problem hiding this comment.
🚀 Design changes LGTM. Fantastic job @Heenawter! Exciting to see our new controls even closer to the legacy ones.
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: cc @Heenawter |

Closes #170396
Closes #135459
Summary
This PR adds the option to stop selections from being auto-applied - instead, authors can make it so that their selections are only applied once the new apply button is clicked:
Screen.Recording.2024-03-04.at.4.39.15.PM.mov
Brief Summary of Changes
Publishing Filters
We used to publish the control group filters as soon as any child changed its output - however, if the apply button is enabled, this logic no longer works. So, we added an extra step to the publishing of filters:
unpublishedFiltersarray.unpublishedFiltersarray.Unsaved Changes
We used to publish control group unsaved changes whenever anything about the children panels' persistable input changed - however, this no longer works with the apply button because we don't want selections to trigger unsaved changes when it is enabled.
To get around this, we no longer take into account selections when checking for unsaved changes - instead, we compare the output filters from the control group to determine whether anything about the children changed. As described above, if the control group has "auto-apply selections" turned off, the control group waits to change its output until the apply button is clicked - therefore, unsaved changes will also not be triggered until the apply button is clicked. This unsaved changes logic works regardless of if the apply button is enabled or not.
Saved Object
This required changes to the dashboard saved object because of how we store the control group input as part of the dashboard SO - so, we are now on a second version for the Dashboard SO. I've also made this version slightly less strict by allowing unknown attributes in the schema - that way, unknown attributes will no longer throw an error (as they do on version 1).
Checklist
For maintainers