* [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
* 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.
* Only throw the error about building the DLL if we're not running in Jest
* Update existing storyshots
* Add Jest mock for Datasource story
All tests look to be passing and `yarn storybook canvas` works. I clicked through all the stories and it doesn't look like anything is broken.
* Reused the naming scheme for field column in conditions table.
* Updated snapshot.
* update Operator value to show as `is`
* Update Jest snapshot
Co-authored-by: Paul Tavares <paul.tavares@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Prevent react warnings for unknown `isVisible` prop
Unknown config options ultimately become attributes on an anchor/button
element, so we need to not overload these config objects.
* Fix react warning about unknown `isDisabled` prop
There is no `isDisabled` prop on the underlying `EuiFieldText`
component, so we should use the native `disabled` attribute instead.
* Fix warning about switching between un-/controlled componenents
On the first few renders, our input refs have not been set while a
default value has, so the length of our values is 1 while our refs is 0.
This causes us to hit the 'else' condition of our ternary, leading to an
input with no value. When the ref is then populated, a value is
generated and so is the error.
The previous logic here was always evaluating to `value: item` and so was
simplified.
* Fix jest warning on unexpected state update
* removes unnecessary use of act()
* renders our component within the test
* This allows our test to synchronize with react and prevents the
warning; I suspect it has something to do with the scoping of
`wrapper` or the `beforeEach` not being async, but I haven't had
time to investigate.
* Remove unnecessary test guards
These tets no longer throw warnings.
