[Security Solution][Auto migrations] Add support for hiding data errors in the ESQL editor
Summary
issue: https://github.com/elastic/security-team/issues/11535
Adds the switch to toggle data errors highlighting in the ESQL editor when used inside the automatic migrations.
Implementation details
- A new
dataErrorsControlproperty is exposed by the ESQL editor component to allow controlling the "data errors" switch state from outside. The type is defined as follows:
export interface DataErrorsControl {
enabled: boolean;
onChange: (value: boolean) => void;
}
-
The ESQL editor is responsible for:
- Rendering the switch according to the
dataErrorsControlstate provided. - Hide the data errors highlighting when the dataErrorsControl.enabled is
false(strictly) - Not rendering the switch when
dataErrorsControlis not provided, and highlighting data errors.
- Rendering the switch according to the
-
The Automatic migrations flyout in Security that uses the ESQL editor is responsible for:
- Managing the state of the
dataErrorsControlprovided to the editor. - Persist the state to local storage to be shared between all the instances of the ESQL editor on that page.
- Managing the state of the
Considerations
-
Managing the "data errors" switch state internally in the ESQL editor would make it hard to apply this behaviour (including local storage persistence) only in the Automatic migrations page in Security.
-
The "data errors" validation is performed even when the highlighting is disabled. The number of errors is necessary anyway, to know whether the "N errors" popover button in the footer (where the switch is displayed) should be rendered or not.
Screenshots
Data errors enabled:
Data errors disabled (highlights syntax errors only):
Edge cases
No syntax errors
When there are data errors but no syntax error, and the switch is off, we render the 0 errors popover button:
just to be able to turn the switch on and see the underlying data errors:
No errors
When there is no error at all, we hide the N errors popover button, regardless of the switch value:
Pinging @elastic/security-threat-hunting (Team:Threat Hunting)
Thanx! I will review tmr!
@elasticmachine merge upstream
:hourglass_flowing_sand: Build in-progress, with failures
- Buildkite Build
- Commit: 6ed59b37bdc60878c3492c57c616d125bbdfadae
Failed CI Steps
History
- :yellow_heart: Build #308779 was flaky 624cc60cf9a9d92bebd2f074fe015ac66bcbde4a
- :green_heart: Build #308426 succeeded 96bb726749c083eb90c42eaa321eccafc383527d
- :green_heart: Build #308277 succeeded 91b6c86d07d982d57a4880ca7cd792f8b8fe1860
- :broken_heart: Build #308216 failed eda37395e69cb6f29c56970773fce1783a0474f5
cc @semd
Starting backport for target branches: 8.19
https://github.com/elastic/kibana/actions/runs/15726806630
💚 All backports created successfully
| Status | Branch | Result |
|---|---|---|
| ✅ | 8.19 |
Note: Successful backport PRs will be merged automatically after passing CI.
Questions ?
Please refer to the Backport tool documentation