* [RAC] create functional tests for add to case
* use observability test helpers for user creation
* basic tests for add to case options
* add two more cases
* test case for clicking on add to new case button
* remove unused expect statement
* clicking on add to existing case should open a modal
* move add to case functionality in a separate file
* address comments in the PR review
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Hide refresh button by prop and refactor unit test
* Add test cases for policies selector when enable/disable license
* Remove unused code when adding mock
## Summary
Fixes: https://github.com/elastic/kibana/issues/114535
**What this linter rule does:**
* Sets the [@typescript-eslint/no-non-null-assertion](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-assertion.md) linter rule to become an error if seen.
If you try to use the `!` operator you get an error and nice helper message that tries to encourage better practices such as this one:
<img width="1635" alt="Screen Shot 2021-10-07 at 11 26 14 AM" src="https://user-images.githubusercontent.com/1151048/136474207-f38d3461-0af9-4cdc-885b-632cb49d8a24.png">
**Why are we deciding to set this linter rule?**
* Recommended from Kibana [styleguide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.mdx#avoid-non-null-assertions) for ~2 years now and still recommended.
* A lot of TypeScript has evolved and has operators such as `?` which can replace the `!` in most cases. Other cases can use a throw explicitly or other ways to manage this.
* Some types can change instead of using this operator and we should just change the types.
* TypeScript flows have improved and when we upgrade the linter will cause errors where we can remove the `!` operator which is 👍 better than leaving them when they're not needed anymore.
* Newer programmers and team members sometimes mistake it for the `?` when it is not the same thing.
* We have had past bugs and bugs recently because of these.
* It's easier to use the linter to find bugs than to rely on manual tests.
**How did Frank fix all the 403 areas in which the linter goes off?**
* Anywhere I could remove the `!` operator without side effects or type script errors I just removed the `!` operator.
* Anywhere in test code where I could replace the code with a `?` or a `throw` I went through that route.
* Within the code areas (non test code) where I saw what looks like a simple bug that I could fix using a `?? []` or `?` operator or `String(value)` or fixing a simple type I would choose that route first. These areas I marked in the code review with the words `NOTE:` for anyone to look at.
* Within all other areas of the code and tests where anything looked more involved I just disabled the linter for that particular line. When in doubt I chose this route.
### 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
* Add icons
* Add new categories
* Add Workplace Search connectors to the unified integrations view
* Add a new enterprise_search shipper
* Update number of custom integrations in test
* Change customIntegrations type to optional
* Revert "Update number of custom integrations in test"
This reverts commit 30214b2c7c.
The reason is that while this test passes with 2 separate commands for
functional test runner, it fails when it is run with a single command.
Reverting to make the CI pass. We will look into this test separately.
I will link the investigation issue in the PR.
* Change source deletion to set entire page loading
Do this instead of having the button loading
* Replace text button with icon button for blocked windows
* Adding execution duration to get alert instance summary
* Showing execution duration on rule details view
* Fixing unit tests
* Updating to match new mockup
* Fixing types
* Fixing functional test
* Removing unneeded max and min and adding tests
* Removing unneeded max and min and adding tests
* Fixing functional test
* Adding left axis
* PR feedback
* Reducing chart height
* PR feedback
* PR feedback
* PR feedback
* fixing throughput chart api
* change backends
* adding intervalString to the observability callback functions
* fixing transaction group detailed stats
* fixing tests
* fixing test
* fixing obs tests
* fixing tests
* adding tests
* fixing ci
* using data generator
* changing name
* fixing i18n
* updating opbs test to use data generator
* fixing api tests
* fixing tests
* using data generator to run the tests
* fixing tests
* fixing test
* Add new toggle
* [ML] Add tooltip for p value
* [ML] Add tooltip for p value
* Update tooltip
* Add callback, revert i18n, compressed
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* 🐛 First attempt to close the inspector automatically on app unmount
* 👌 Integrate feedback
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
**Ticket:** https://github.com/elastic/kibana/issues/109815
## Summary
**Background:** `siem-detection-engine-rule-status` documents stores the `lastFailureMessage` a string which is indexed as `type: "text"` but some failure messages are so large that these documents are up to 26MB. These large documents cause migrations to fail because a batch of 1000 documents easily exceed Elasticsearch's `http.max_content_length` which defaults to 100mb.
This PR truncates `lastFailureMessage` and `lastSuccessMessage` in the following cases:
1. When we write new or update existing status SOs:
- The lists of errors/warnings are deduped -> truncated to max `20` items -> joined to a string
- The resulting strings are truncated to max `10240` characters
2. When we migrate `siem-detection-engine-rule-status` SOs to 7.15.2:
- The two message fields are truncated to max `10240` characters
### Checklist
Delete any items that are not applicable to this PR.
- [ ] [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
* [Reporting] Functional test structure & improvements
* show the error of the report generation failure in the test failure
* update snapshot
* remove import to non-existent functional app test
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* ✨ compute the default threshold based on data bounds
* 🐛 Fix multi layer types issue
* ✅ Fix test
* ✅ Fix other test
* 🐛 Fix computation bug for the initial static value
* ✅ Add new suite of test for static value computation
* 🐛 Fix extents bug and refactor in a single function + tests
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* WIP replacing indexPattern.flattenHit by tabify
* Fix jest tests
* Read metaFields from index pattern
* Remove old test code
* remove unnecessary changes
* Remove flattenHitWrapper APIs
* Fix imports
* Fix missing metaFields
* Add all meta fields to allowlist
* Improve inline comments
* Move flattenHit test to new implementation
* Add deprecation comment to implementation
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Enabled auto policy upgrades for APM and Synthetics
* fixup! Enabled auto policy upgrades for APM and Synthetics
* Rework preconfiguration policy upgrade flow + report errors
* Fix type error in test
* Fix type errors + tests
* wip
* Remove keep policies up to date checks
* Remove references to KEEP_POLICIES_UP_TO_DATE_PACKAGES
* Move package policy upgrade results to nonFatalErrors
* Fix types
* Fix type error
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
A change in the ES range agg no longer accepts numbers with decimals if the underlying field is typed as long. This fixes the issue by rounding the values we pass on to the range agg.
