* rename uuid service to environment service
* adapt resolve_uuid to directly use the configurations
* move data folder creation to core
* update generated doc
* fix types
* fix monitoring tests
* move instanceUuid to plugin initializer context
* update generated doc
## Summary
Found in 7.9.0, if you post a rule with an action that has a missing "meta" then you are going to get errors in your UI that look something like:
```ts
An error occurred during rule execution: message: "Cannot read property 'kibana_siem_app_url' of null"
name: "Unusual Windows Remote User" id: "1cc27e7e-d7c7-4f6a-b918-8c272fc6b1a3"
rule id: "1781d055-5c66-4adf-9e93-fc0fa69550c9" signals index: ".siem-signals-default"
```
This fixes the accidental referencing of the null/undefined property and adds both integration and unit tests in that area of code.
If you have an action id handy you can manually test this by editing the json file of:
```ts
test_cases/queries/action_without_meta.json
```
to have your action id and then posting it like so:
```ts
./post_rule.sh ./rules/test_cases/queries/action_without_meta.json
```
### 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
**Current behavior:**
- **Scenario 1:** User is in the exceptions viewer flow, they select to edit an exception item, but the list the item is associated with has since been deleted (let's say by another user) - a user is able to open modal to edit exception item and on save, an error toaster shows but no information is given to the user to indicate the issue.
- **Scenario 2:** User exports rules from space 'X' and imports into space 'Y'. The exception lists associated with their newly imported rules do not exist in space 'Y' - a user goes to add an exception item and gets a modal with an error, unable to add any exceptions.
- **Workaround:** current workaround exists only via API - user would need to remove the exception list from their rule via API
**New behavior:**
- **Scenario 1:** User is still able to oped edit modal, but on save they see an error explaining that the associated exception list does not exist and prompts them to remove the exception list --> now they're able to add exceptions to their rule
- **Scenario 2:** User navigates to exceptions after importing their rule, tries to add exception, modal pops up with error informing them that they need to remove association to missing exception list, button prompts them to do so --> now can continue adding exceptions to rule
* Adding kql filter
* Adding filter support for the backend and tests
* Moving the filter to the body
* switching events and alerts api to post
* Removing unused import
* Adding tests for events api results being in descending order
* Switching frontend to use post for related events
* Reset chrome help extension while switching an app
* Reset other chrome fields
* Set docTitle in saved objects app
* Add unit tests
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Before this PR you can see event loop block times of:
```ts
formatIndexFields: 7986.884ms
```
After this PR you will see event loop block times of:
```ts
formatIndexFields: 85.012ms
```
within the file:
```ts
x-pack/plugins/security_solution/server/lib/index_fields/elasticsearch_adapter.ts
```
For the GraphQL query of `SourceQuery`/`IndexFields`
This also fixes the issue of `unknown` being returned to the front end by removing code that is no longer functioning as it was intended. Ensure during testing of this PR that blank/default and non exist indexes within `securitySolution:defaultIndex` still work as expected.
Before, notice the `unknown` instead of the `filebeat-*`:
<img width="733" alt="Screen Shot 2020-08-20 at 4 55 52 PM" src="https://user-images.githubusercontent.com/1151048/90949129-f5047900-e402-11ea-9278-b4c7bf5cd16d.png">
After:
<img width="830" alt="Screen Shot 2020-08-20 at 4 56 03 PM" src="https://user-images.githubusercontent.com/1151048/90949133-02b9fe80-e403-11ea-8504-f5bbe043048a.png">
An explanation of how to see the block times for before and after
---
For perf testing you first add timed testing to the file:
```ts
x-pack/plugins/security_solution/server/lib/index_fields/elasticsearch_adapter.ts
```
Before this PR, around lines 42:
```ts
console.time('formatIndexFields'); // <--- start timer
const fields = formatIndexFields(
responsesIndexFields,
Object.keys(indexesAliasIndices) as IndexAlias[]
);
console.timeEnd('formatIndexFields'); // <--- outputs the end timer
return fields;
```
After this PR, around lines 42:
```ts
console.time('formatIndexFields'); // <--- start timer
const fields = await formatIndexFields(responsesIndexFields, indices);
console.timeEnd('formatIndexFields'); // <--- outputs the end timer
return fields;
```
And then reload the security solutions application web page here:
```
http://localhost:5601/app/security/timelines/default
```
Be sure to load it _twice_ for testing as NodeJS will sometimes report better numbers the second time as it does optimizations after the first time it encounters some code paths.
You will begin to see numbers similar to this before this PR:
```ts
formatIndexFields: 2553.279ms
```
This indicates that it is blocking the event loop for ~2.5 seconds befofe this fix. If you add additional indexes to your `securitySolution:defaultIndex` indexes that have additional fields then this amount will increase exponentially. For developers using our test servers I created two other indexes called delme-1 and delme-2 with additional mappings you can add like below
```ts
apm-*-transaction*, auditbeat-*, endgame-*, filebeat-*, logs-*, packetbeat-*, winlogbeat-*, delme-1, delme-2
```
<img width="980" alt="Screen Shot 2020-08-21 at 8 21 50 PM" src="https://user-images.githubusercontent.com/1151048/90949142-211ffa00-e403-11ea-8ab2-f66de977dce3.png">
Then you are going to see times approaching 8 seconds of blocking the event loop like so:
```ts
formatIndexFields: 7986.884ms
```
After this fix on the first pass unoptimized it will report
```ts
formatIndexFields: 373.082ms
```
Then after it optimizes the code paths on a second page load it will report
```ts
formatIndexFields: 84.304ms
```
### 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
Restore the resolverTest plugin. This will allow us to run the test plugin and try out Resolver using our mock data access layers. Eventually this could be expanded to support multiple different data access layers. It could even be expanded to allow us to control the data access layer via the browser. Another option: we could export the APIs from the server and use those in this test plugin.
We eventually expect other plugins to use Resolver. This test plugin could allow us to test Resolver via the FTR (separately of the Security Solution.)
This would also be useful for writing tests than use the FTR but which are essentially unit tests. For example: taking screenshots, using the mouse to zoom/pan.
Start using: `yarn start --plugin-path x-pack/test/plugin_functional/plugins/resolver_test/`
## Summary
Assert unreachable was created through advice given by both the Typescript community and through the techniques that TyepScript is trying to achieve type safety with switch statements.
This fixes recent bugs by:
* Re-adding the never type
* Reduces the two different types by putting the helper within the common section so there's not duplication
* Fixes on type that looks like it was a regular string rather than a one of the enum types
The reasoning for exhaustive checks within switch statements and techniques can be seen in numerous areas such as here:
https://stackoverflow.com/questions/39419170/how-do-i-check-that-a-switch-block-is-exhaustive-in-typescript
You can do it either way with TypeScript as long as you ensure you have a explicit return type and you do early return statements you can actually avoid having to call into the assertUnreachable.
If introduced and used correctly it is there to help out like this error it is telling us that this string type is not exhaustive:
<img width="921" alt="Screen Shot 2020-08-24 at 10 39 42 AM" src="https://user-images.githubusercontent.com/1151048/91075618-9b1ad380-e5fb-11ea-9200-1c355faf5dca.png">
You can notice that for this pull request I actually remove the assertion like so if someone accidentally removes one of the switch statements:
<img width="1014" alt="Screen Shot 2020-08-24 at 10 42 08 AM" src="https://user-images.githubusercontent.com/1151048/91075662-a968ef80-e5fb-11ea-8d74-a92eedd63892.png">
And since the function has an explicit return type it is not needed. You will see that TypeScript improved its never types behind the scenes where it actually will tell you that it will never reach the `assertUnreachable` and want to remove it as an auto-refactor. That is ok as long as we have explicit return types and what I did with one line of code here.
<img width="536" alt="Screen Shot 2020-08-24 at 11 21 05 AM" src="https://user-images.githubusercontent.com/1151048/91075861-efbe4e80-e5fb-11ea-9991-dda111a04f1d.png">
Without this fix, and having the never type become an unknown it introduces less safety where any code that is utilizing the assertUnknown without explicit return types will be prone to having run time errors being thrown when something new is added to their switch enum types.
* changing transaction type filter to radio group
* fixing unit test
* changing transaction type filter to radio group
* adding onclick to the badge component
* adding onclick to the badge component
* adding i18n to aria
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
resolves https://github.com/elastic/kibana/issues/68209
Since routing key figures fairly prominently throughout PagerDuty APIs,
and ours, it seems like it make sense to include it in the single validation
message we have for it, as well as using the term we use for it in the product:
"integration key".
See the referenced issue for more background.
* Fixed alerting_api_integration/security_and_spaces tests failing if actions proxy set on for parallel process running using commands 'scripts/functional_tests_server' and 'scripts/functional_test_runner'
* -
* Fixed get port from range for Slack and webhook simulators, removed some test warnings
* Added check for listening proxy server
* changed logger to debug removed not useful error
* -
* changed proxy to dynamic target in a single place
* test retry
* -
* -
* -
* -
* test with no cleanup
* -
* -
* -
* -
* Added environment variable ALERTING_PROXY_PORT
* fixed type checks
* fixed clean up proxy server port
* Rename Whitelist to AllowList in Actions and Alerting
* revert not related change
* Fixed due to comments and tests failing
* Fixed failing tests
* Fixed due to comments
