* [Enterprise Search] Migrate Kibana plugin to TS project references
Part of #80508
* Add charts and un-comment added ‘features’
Also alphabetize.
* Uncomment recently added security and spaces
* Add last remaining reference
* Add shared typings to cover svgs
* Include package.json for version.ts
* REvery adding package.json to include
This did not fix the issue
* Add correct references
* Adding es query alert type to server with commented out executor
* Adding skeleton es query alert to client with JSON editor. Pulled out index popoover into component for reuse between index threshold and es query alert types
* Implementing alert executor that performs query and matches condition against doc count
* Added tests for server side alert type
* Updated alert executor to de-duplicate matches and create instance for every document if threshold is not defined
* Moving more index popover code out of index threshold and es query expression components
* Ability to remove threshold condition from es query alert
* Validation tests
* Adding ability to test out query. Need to add error handling and it looks ugly
* Fixing bug with creating alert with threshold and i18n
* wip
* Fixing tests
* Simplifying executor logic to only handle threshold and store hits in action context
* Adding functional test for es query alert
* Types
* Adding functional test for query testing
* Fixing unit test
* Adding link to ES docs. Cleaning up logger statements
* Adding docs
* Updating docs based on feedback
* PR fixes
* Using ES client typings
* Fixing unit test
* Fixing copy based on comments
* Fixing copy based on comments
* Fixing bug in index select popover
* Fixing unit tests
* Making track_total_hits configurable
* Fixing functional test
* PR fixes
* Added unit test
* Removing unused import
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* cleaning up unused types and legacy logic
* added new relative age logic with unit tests
* initial implementation of timeline
* added custom infinity icon to timeline component
* added comment
* move timeline color bar comment
* fix nanoseconds and microsecnds bug
* added policy timeline heading, removed "at least" copy for now
* a few minor changes
- fix up copy
- fix up responsive/mobile first view of timeline
- adjust minimum size of a color bar
* minor refactor to css classnames and make trash can for delete more prominent
* added delete icon tooltip with rough first copy
* added smoke test for timeline and how it interacts with different policy states
* update test and copy
* added basic a11y tests for ILM policy list view and create/edit policy view
* remove unused import
* remove old svg file
* remove old _timeline.scss file
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [ML] Stabilize accessibility tests for data frame analytics pages
* [ML] Remove snapshot test after opening index pattern modal
* [ML] Remove snapshot test when index pattern modal opens
* [ML] Add back snapshot test at index pattern modal step
* [Event Log] Added KQL queries support for Event Log API.
* refactored to use core.elasticsearch.client
* Fixed tests
* removed get index pattern for event log
* Fixed tests
* Fixed due to comments.
* Remove ActionsConfigType due to being a duplicate
* Fix rejectUnauthorized not being configured
* Move proxySettings to configurationUtilities
* Fix isAxiosError check to code
* Add functional test
* Remove comment
* Close webhook server
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
After observing the conditions when this test fails, it appears that
some (but not all) signals are available. As these signals are generated by a
rule via a bulk create, the odds of us retrieving signals in the middle
of that bulk creation is very slim (but not impossible).
The crux of the error here was: we wait for signals to be generated, but
not the ones that we need. Specifically, we are waiting for a single
signal to be available, but since we are asserting on sequences of
signals, we need several to be available to us.
While not perfect (because the signals we receive are not technically
guaranteed to be sequence signals), increasing the number of signals
that we wait for before proceeding should be sufficient to prevent this
failure state. In debugging, it was observed that every test returning
9-10 signals succeeded, while it was possible for the test to return
only one signal and fail.
* change from type:gauge to type:top_n in inventory models
* Add test for hostSystemOverview metric
* fix lint errors
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Enable v2 so migrations, disable in FTR tests
* Disable v2 migrations for ui_settings integration tests
* Disable v2 migrations for reporting without serucity api integration test
* fixes https://github.com/elastic/kibana/issues/74449
* watcher test with specific permissions
* adding the false parameter
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/68575
The index threshold alert defines an `index` parameter which is
typed as `string | string[]`. However the UI for this alert has
been typing it as only `string[]`.
This PR changes the UI to work with an incoming string value for
this parameter. If the parameter is edited in the UI, it will always
be set as an array, even if there is only one element.
* [Maps] fix users without access to Maps should not have the option to create them
* fix test message
* wrap add geo field trigger in show capabilities check
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
When something causes an exception in `TaskRunner.markTaskAsRunning()` its execution fails, but this happens before we update the SO, which means that this failure does not count towards the `attempts` on the task. Task Manager will continue to try running this task for ever.
This PR increments the `attempts` when a failure occurs during `TaskRunner.markTaskAsRunning()` to ensure such a task doesn't continue to run to infinity.
Note that this fix will not affect `scheduled` tasks, as they are designed to _ignore_ their `attempts` and run for ever. In such a case this task will continue to consume Task Manager resources until canceled, but these failures will be logged and could be identified when needed.
