* [TSVB] Add ignore global filters to series options
* Disable ignore global filter option for series when it's disabled in the panel options
* Moving EuiFlexGroup into SeriesConfigQueryBarWithIgnoreGlobalFilter
* Fixing translations
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [Maps] clean up uses of any in redux actions and kibana services
* API doc changes and updated IndexPatternSelect type
* tslint errors in OSS code
* API updates
* remove IndexPatternSelectPublicProps and create IndexPatternSelectInternalProps instead
* include changes to index_pattern_select
* API updates
* remove savedObjectClient from IndexPatternSelectProps
* update types for lazy load component
* remove unused import
* export type
* another API clean-up
* revert changes to import in data/public/types
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [ML] fix job selection flyout
* [ML] hide time range column
* [ML] show callout when no AD jobs presented
* [ML] close job selector flyout on navigating away from the dashboard
* [ML] add Create job button
* [ML] fix mocks
* [ML] add unit test for callout
## Summary
If you had two different index patterns for threat and your query I was previously sending the same pattern in for both which was causing drop down boxes for threat match to null things out. Now, I set the two different indexes correctly.
### Checklist
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
## Summary
Fixes https://github.com/elastic/kibana/issues/79865
Also fixes:
* Timestamp override not being pushed down into threshold rules to use
* Timestamp override not being used for lastValidDate
* The return format of the date time might have been different depending on the customer mapping for both the override and the regular @timestamp so this fixes that as well.
* Fixes one small type issue with fields.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
* commiting change for the dismiss Banner
* Change comments
* Change timeout and gziped data file
* Fixed banner list fail
* Moved dismiss Banner code to the common_page.ts
* Remove find from host_page
* Remove comments from host_page
* Added Expected data to the related Evens
Renamed tests from Child events to Related Events
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Write failing status when executionStatus is in error
* adds unit test for error handling if rule status service throws an error
* adds success test for when executionStatus is failed
* moves logic for writing executionStatus failure to rule status saved object inside find rules status route, updates find rules route to display error if executionStatus is in error, but not be in charge of writing the status. That job belongs to the find rules status route.
* test if we are writing an error status when calls are made to find_rules_status_route and adds a test for general error checking
* adds JSDocs description for rules status route, updates findRules filter to append rule ids to the end of query, removes object.keys()
* don't write an error to our rule status in the route, only read from the executionStatus property and merge that result with our stored failures
* fixes tests
* move mock rule status service out of __mocks__ folder and remove unnecessary references to mock in tests
* fix type error
* updates json.gzip for cypress
* PR feedback
* fix timing issue with integration tests
* removes unzipped data.json
## Summary
This PR chips a bit at some stricter value validations that have been discussed. Further validation is needed, but this adds some more basic validation.
- **Current:** if selected field is of type `boolean` users can add custom values in combo box
- **Now:** if selected field is of type `boolean` users can only select `true` or `false`
- **Current:** if selected field is of type `number` (that is kibana type number) user can input any values
- **Now:** if selected field is of type `number` and no autocomplete suggestions are available, number input is used to restrict users
- **Current:** for operator `match_any` it's conducting an autocomplete search after each selection resulting in some jumpy/weird behavior
- **Now:** only conducts autocomplete search on initial field selection and if user enters value to search
- **Current:** only validations on type date
- **Now:** validation on type (Kibana type) date, number
- **Current:** input would show red when there was an error but user could still submit
- **Now:** submit button is disabled if error exists
* Rename types from the top-level plugin
These are the same types with a different name. However, the benefit is
that they exist in a non-restricted path (the top level of the plugin).
* Convert our validation function to use the EQL search strategy
Rather than calling our custom EQL validation endpoint, we can instead
leverage the EQL search strategy. The downside is that we have to move
our response parsing logic to the frontend, but the benefit is that
there's no backend to maintain.
* Remove server code related to our EQL validation endpoint
We're keeping our io-ts schemas for now since they're still being used
to type the I/O of our client function.
* Add the data contract to our KibanaServices
I'm not aware of a way to pass react context to the form lib validator
functions, so for now we have to pass this the ugly way :(
* Remove io-ts types corresponding to our defunct validation endpoint
We were keeping these around for the types, but they're so simple that
it's really not worth the overhead. The tests are similarly for
functionality that is no longer used, so no hard feelings there.
* Ensure that our validation does not bother generating hits
We only care about the query's validity, so we can tell the response
handler to do less work here.
* Pass transport options when retrieving an existing search
Without passing transport options to .get, a query with an `ignore`
would succeed if it completed in the `waitForCompletionTimeout` window,
but fail (with the ignored error) on the subsequent request if it became
async.
* Use constant for our strategy key
* Export search strategy constants for client consumption
Common values cannot be consumed directly by client code (compilation
error), so we need to re-export them from data_enhanced's public module.
## Summary
Right now even though it is not 100% ECS compliant a user can create a source index that has records which do not have the `@timestamp` but rather utilizes their own timestamp data and then within the detection engine they do an "override" to utilize that other timestamp.
To reproduce this simply add a lot of data records to an index and omit the `@timestamp` and then use the detection engine override to choose a different date timestamp. Before this fix you will see errors showing up during rule run even though it still does produce valid signals.
After this fix, you will not get errors showing up as we do not allow unusual things such as:
```ts
new Date(undefined).toISOString()
```
To occur which is what does the range throw. If you are on the estc server you can use the mapping I created called:
```ts
delme-alert-customer
```
With the override of `triggered`
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
### Summary
This PR introduces a preview histogram feature inside the rule creation workflow, that gives users insight to how effective the rule is for triggering alerts the user would like to see.
* Clean up our component types
* Clamp our Rule Schedule inputs to safe values
* If the user enters a value > Number.MAX_SAFE_INTEGER, it will be
updated to Number.MAX_SAFE_INTEGER
* If the user enters non-numeric text, it will be updated to 0
* Ensure that we do not go below the default value
0 is not necessarily a reasonable default, but we already have a
variable for the default value.
* Update cypress interaction with schedule fields
Now that we set defaults for bad values, it's no longer possible to
"clear" the numeric input. However, to get roughly the same behavior we
can instead select the current value and start typing.
