## Summary
Re-enables the release test that sometimes is flaky as updating metadata
for isolation status may be slow.
Should also close elastic/kibana/issues/172204 which is also flaky for
the same reason.
closes elastic/kibana/issues/172418
closes elastic/kibana/issues/172204
### Flaky test runner
-
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/4775
x 100 ( all green )
### Checklist
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## Summary
This PR enables a retry for failed FTR MKI tests when triggered from the
quality gates pipelines.
The retry has recently been introduce to that pipeline for all runs and
has now been modified to be controlled by an environment variable. This
PR adds the corresponding change to the calling pipelines.
## Summary
Closes https://github.com/elastic/ingest-dev/issues/2779
Adding the kibana version to the list of available agent versions if the
product versions api doesn't return any versions (not accessible or
airgapped environment). This is a best effort fix to add the missing
latest released version if the build version list is outdated.
To verify:
1. test with internet connection
- enroll an agent with the latest version 8.11.3 locally or in a VM (not
container)
- check that the upgrade available badge is not showing up and the add
agent instructions have 8.11.3 version
<img width="1324" alt="image"
src="b833c92e-3864-4a0b-a26b-0cf927b95a80">
<img width="814" alt="image"
src="bb21a63a-dbd5-4557-b81d-93391bbc51a9">
Restart kibana or wait 10m for the cache to expire before testing with
air gapped.
2. test air-gapped by adding `xpack.fleet.isAirGapped: true` in
kibana.yml
- test that the agent shows up with the badge upgrade available, and the
upgrade agent modal has 8.13 version locally
- check that the add agent instructions have the 8.13 version (current
kibana version)
<img width="1294" alt="image"
src="81df38c4-cc35-466b-9d41-c226b8b29563">
<img width="818" alt="image"
src="0a1b72d8-be3c-4cbf-9f44-30a7f7aef02a">
### 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
Closes#172506
## Summary
This PR adds a button to all APM pages navigating to a feedback form.
The feedback button component exists in infra so in this PR the
component is changed to meet the new requirements and moved to
`observability_shared`. Now the feedback button component supports also
prefilling the sanitized path (`entry.1876422621`). The requirements
picked for the sanitized path are described in the issue - it should be
for example `/app/apm/{page_name}` if the user is on the page with the
exact path matching `/app/apm/{page_name}` and `/app/apm/{page_name}*`
for all subpages (for example `/app/apm/{page_name}/something/else`) -
different test scenarios can be found in the unit test:
[get_path_for_feedback.test.ts](https://github.com/elastic/kibana/compare/main...jennypavlova:kibana:172506-obsux-add-feedback-form-to-apm?expand=1#diff-6396807e61353509c44fa38488dfb741549e60f25126024b92596f6b7ac933b8)
## Testing
- Go to APM
- All APM pages should have a yellow button with the text: `Tell us what
you think!`
- Hover on the button to see the prefilled properties and check if every
property is prefilled
<img width="1920" alt="image"
src="b57adf04-4e7b-42bb-827f-db554dc4a842">
- Click on the form and check if the form is prefilled - The questions
that should be prefilled in APM
- Where is your Elastic cluster deployed? (same as infra)
- By default, the pre-selected option will be on-prem
- To test the case with the cloud option preselected add
`xpack.cloud.id: 'elastic_kibana_dev'` to your `kibana.dev.yaml`
- To test the serverless option run Kibana in serverless mode
(observability config)
- What version of Elastic are you using? (same as infra)
- Where in the UI are you?
- After checking the APM go to the infra pages and check the feedback
button/form
52cc886f-95a9-4099-b047-93fc64036572
## Summary
This PR removes the legacy kibana react code-editor, alongside replacing
all import declarations of this legacy component to the one offered by
shared-ux, i.e import declaration source of `'@kbn/kibana-react/public'`
is switched to `@kbn/code-editor`.
Also in this PR an helper for writing jest tests has been included
through the package `@kbn/code-editor-mock`, this would facilitate
mocking the editor, especially given that the code editor leverages
couple of APIs that are aren't included by default in jsdom, among them,
`matchMedia`, `ResizeObserver`. The provided mock is sufficient for most
use cases and can be setup in any package within kibana as a
[`node_module`
mock](https://jestjs.io/docs/manual-mocks#mocking-node-modules) without
having to repeatedly manually mock the editor within individual test
files. An example for how this might be done can be found here
ec5ba25368
### Checklist
<!-- Delete any items that are not applicable to this PR.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
-->
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
<!--
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/security-team/issues/8099**
## Summary
This PR adds an a command to lint OpenAPI specs defined in Security
Solution plugin.
## Details
We have a number of OpenAPI specs defined in Security Solution plugin.
While `@kbn/openapi-generator` package processes the specs and makes
sure the specs are parsable and processable we don't have proper specs
linter set up.
This PR introduces OpenAPI specs linting by leveraging [Redocly
CLI](https://github.com/Redocly/redocly-cli)'s `lint` command with a
custom configuration placed in `@kbn/openapi-generator` package .
Configuration includes reasonable best practices by using [built-in
Redocly rules](https://redocly.com/docs/cli/rules/built-in-rules/).
The lint utility fulfil the following requirements
- Validates yaml files against OpenAPI specification. It supports `3.0`
and `3.1`.
- Validates `x-modify` property to have only `partial`, `required` or
`requiredOptional` values.
- Checks for reasonable best practices and displays a warning message
when it's not met. Reasonable best practices are based on the
[recommended
ruleset](https://redocly.com/docs/cli/rules/recommended/#recommended-ruleset).
The lint utility has been incorporated into the existing OpenAPI
generator, and linting is performed before generation.
### Tool selection
[Swagger CLI](https://github.com/APIDevTools/swagger-cli) is a well
known tool to validate OpenAPI specs. On November 15th 2023 the repo has
been archived with a message in README
> ⚠️ Swagger CLI has been deprecated, due to the maintenance burnden of
trying to keep up with expectations of a huge userbase with little to no
pull requests or support. [Redocly
CLI](https://redocly.com/redocly-cli/) covers all of the same
functionality, and has more advanced linting with custom rules, and we
highly recommend using that instead. They have conveniently provided a
[migration
guide](https://redocly.com/docs/cli/guides/migrate-from-swagger-cli/)
for existing Swagger CLI users. Read the review of [Redocly CLI from
APIs You Won't Hate](https://apisyouwonthate.com/blog/redocly-cli/).
Taking it into account choice falls on **Redocly CLI**.
## How to test?
Change directory to Security Solution plugin's root and run linting by
using the following commands from Kibana root
```sh
cd x-pack/plugins/security_solution
yarn openapi:generate
```
---------
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/167632
This PR provides a simpler api for the Lens embeddable consumers who
want to provide inline editing capabilities. I added an example to help
with the integration. Run kibana with
```
yarn start --run-examples
```
http://localhost:5601/app/lens_embeddable_inline_editing_example
<img width="1381" alt="image"
src="58e7ef2d-2f92-4bab-9cb4-d04a90d87e15">
<img width="2498" alt="image"
src="0a050e8d-f22f-4c48-88e4-20c42683a279">
It also allows the consumers to render the inline editing component in a
custom element in case you don't want to open a push flyout.
I included a readme on how to use the api.
### Note
This is the first PR which uses the new Lens config builder so some of
the changes are not related to the api improvements but they are fixing
some bugs on the builder.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
In this PR, I'm renaming `Generative AI` to `Generative AI for Security`
in the connectors comatibility list so we have a split on Gen AI for
Security and Observability (follow up from
https://github.com/elastic/kibana/pull/173826).
## Screenshots
<img width="419" alt="Screenshot 2024-01-03 at 11 53 00 AM"
src="cb53c304-c96e-42c9-bce2-94b130040907">
<img width="542" alt="Screenshot 2024-01-03 at 11 53 32 AM"
src="6185010a-4b99-4dc7-bf62-9915c7b75a88">
<img width="1008" alt="Screenshot 2024-01-03 at 11 53 39 AM"
src="26301ee6-a50f-40ac-b898-91bf3e67c719">
## To verify
**Connectors**
1. Startup Kibana in trial mode
2. Open the create Bedrock connector flyout from the connectors page
3. Notice the compatibility is only for Security
4. Create a Bedrock connector (input random text in all fields to pass
validation)
5. Open the create OpenAI connector from the connectors page
6. Notice the compatibility is for Security and Observability
7. Create an OpenAI connector (input random text in all fields to pass
validation)
**Security Solution**
9. Navigate to the Security solution (`/app/security/get_started`)
10. Open the AI Assistant on the top right
11. Open the `Conversation Settings`
12. See OpenAI and Bedrock connectors displaying
**Observability**
13. Navigate to the Observability app (`/app/observability/overview`)
14. Open the AI Assistant on the top right
15. Select the actions menu on the top right of the flyout and open `AI
Assistant Settings`
16. Open the default connector dropdown
17. Notice only OpenAI connectors displaying
fixes: https://github.com/elastic/kibana/issues/161239
## Summary
This PR changes how dependencies data is fetched. To mitigate the max
bucket error risk, and, at the same time, keep the compatibility with
the dependencies-related pages that consume the `get_connection_stats`
query, it now paginates the composite aggregation, using smaller batches
of 1k items per pagination.
**10k dependencies**
<img width="826" alt="image"
src="fb277dd9-0a09-48ef-9e3e-fc1d5a4445e8">
**500 dependencies per service**
<img width="821" alt="image"
src="cf8be999-2fa6-44ee-8838-c255fdb9896d">
**Notes:**
Fetching 1k on each iteration might make the page slower;
The max bucket error might still happen depending on the date range or
how services are instrumented.
### How to test
1. Run synthtrace
```
node scripts/synthtrace service_many_dependencies.ts --from=now-15m --to=now --clean
```
2. Navigate to the Dependencies Inventory page
3. Navigate to a service overview and then to the dependency tab
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes#171163
## Summary
This PR adds log rate analysis to the alert details page for one
document count aggregation if the user has a license above platinum.
This is a similar implementation in the log threshold alert details
page.
## 🧪 How to test?
- Create a Custom threshold rule with only one document count
aggregation
- Optional filter, document count aggregation filter, and group by
information will be applied to the query of this component.
- Go to the alert details page, you should see the log rate analysis on
this page
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/174227
Fix wrong field used for kafka ssl key secret input which broke ssl key
on kafka output update.
To verify:
- create a kafka output with Authentication: SSL, fill out cert and key
- verify that the value of the key is stored as secret in
`.fleet-secrets`
- update kafka output (e.g. change name)
- verify that the ssl key is unchanged
<img width="1572" alt="image"
src="3129ca89-af63-42c4-bc8d-4ff7d280e513">
Closes https://github.com/elastic/kibana/issues/167321
PR does not provide any custom fields for payload because geo
containment alert has very little usage and will be [disabled in
serverless](https://github.com/elastic/kibana/pull/174121), with the
goal of deprecating and removing geo containment alert in the future.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mike Côté <mikecote@users.noreply.github.com>
## Summary
Filter manager is not populated within redux if a user navigates to a
url with timeline opened as the first step of entering the app.
InitializeTimeline action is called, but the reducer just ignores any
params at all if the initialize flag is set to true. Since this is only
used in 2 places, and only 1 of which has an argument other than
timelineId, I think this solution is fine. Should only ever result in
fixing this bug it seems, as filterManager is either created anew or
comes directly from the model.
Issue: https://github.com/elastic/kibana/issues/171437
### 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
This PR adds asset criticality to the risk scoring calculation. While
previous work was done to add the resources and client to create/read
asset criticality documents, this PR builds on those to retrieve
relevant criticality records and apply them to the intermediate scores
calculated via elasticsearch.
__Note that the code in this PR that performs the actual
calculation/writing of new risk fields is behind a feature flag.__
### Performance
Since this PR adds new logic to an already tight/important code path, we
need to ensure that we haven't changed behavior nor performance. I've
captured that as a separate task to be done next:
https://github.com/elastic/security-team/issues/8223.
### Compatibility
Behaviorally, without the feature flag enabled, scoring will skip the
criticality workflow and not write new fields (`criticality_level`,
`criticality_modifier`). ~~I still have an outstanding task to validate
whether this will be an issue until criticality is enabled, and do some
smarter short-circuiting.~~ This task uncovered our need for the above
feature flag.
The one behavioral change introduced in this PR _not_ behind a feature
flag is the normalization of our risk category scores.
### Summary of Changes
- Adds an `AssetCriticalityService` which provides the API used by risk
scoring to retrieve criticality records
- Adds new `search` method to the `AssetCriticalityDataClient`: used to
generally retrieve multiple criticality records at once
- Adds functions to calculate a (currently hard-coded) modifier from a
criticality level, and apply it to the risk score via bayesian update
- Moves risk score level calculation into javascript (necessary because
we need the level to account for criticality)
- Moves some risk level code out of threat hunting code and into the
`common/entity_analytics` folder
- Tests and comments throughout
### TODO
- [x] Add new criticality fields to risk score, address upgrade workflow
- [x] Validate that code works without criticality being enabled.
- [x] Bump task version to invalidate old tasks from being picked up in
customer env
Outcome: All three of the above are addressed with:
1. Moving the code responsible for adding new fields behind a feature
flag
([71f1158](71f115800b))
2. Addressing the upgrade path in a subsequent issue
(https://github.com/elastic/security-team/issues/8012)
## How to Review
1. Enable our asset criticality feature flag:
> ```
> xpack.securitySolution.enableExperimental:
> - entityAnalyticsAssetCriticalityEnabled
> ```
2. Create asset criticality records (see API documentation, or follow
[this
test](https://github.com/elastic/kibana/pull/172417/files#diff-43f9f394fb7c8eb0f0ace3f5e75482c56a7233ae7d11d5fdb98a89e6404412c3R276)
as a setup guide
3. Enable risk engine
4. Observe that new fields are written to risk scores' `_source`, but
not mapped/searchable
5. (optional) Observe that the transform subsequently fails 😢
### Checklist
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: Jared Burgett and Ryland Herrick <ryalnd+jaredburgettelastic+rylnd@gmail.com>
## Summary
We just got an
[SDH#814](https://github.com/elastic/sdh-security-team/issues/814) that
tell us that some feature like `KPIs` and `grouping` are not acting as
they should be.
@PhilippeOberti is doing an investigation to check which feature has
been impacted by this bug. This bug has been introduced in this
https://github.com/elastic/kibana/pull/112113 since 8.0.0
I think this simple solution should not impact any features.
Closes https://github.com/elastic/kibana/issues/170786
## Summary
Currently, in order to change a panel title, the most efficient way to
do this (assuming the dashboard is already in edit mode) is to click on
the panel title -> click on the title input in the flyout -> click save
at the bottom of the flyout. Notice that this process currently takes
**three** clicks, which can start to add up if you need to change
multiple titles in one session - so, in order to remove one click from
this process, I've made it so that the title input is **auto focused**
on when opening the settings flyout through the panel title (and not
when it is opened from the context menu).
> [!NOTE]
> I chose to make this auto-focus behaviour conditional on how the
flyout was opened because, from an a11y perspective, it can be jarring
to have your focus taken out of the natural element order (as noted in
the [EUI
docs](https://eui.elastic.co/#/layout/popover#setting-an-initial-focus)).
It feels natural that, in order to change the panel title, you click on
it - so, auto focusing on the title input makes sense, even when using
keyboard controls. However, if you are opening the settings flyout via
the context menu, it is **less likely** that the goal is to change the
title - so, forcing the focus could feel unnatural in this case.
I added tests for this new auto focus behaviour and, since I was
interested in learning a bit more about RTL, I also added a few other
tests for the dashboard panel components. As part of this, I migrated a
few functional tests to unit tests, since this is a faster and more
reliable way to test certain rendering conditionals.
### Video
229c1303-c81d-46b8-a567-76885361d9fa
### 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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes the badge "managed" missing from the data streams list.
The code used to check that the data stream has both conditions for a
managed data streams `meta.managed: true` and `meta.managed_by:
'ingest-manager'`. The check for `ingest-manager` is not coorect since
it's been renamed to fleet. Instead of updating the check though, I
decided to only leave the condition for `meta.managed : true` and I
removed all mentions of "Fleet" from the Data streams tab. I believe
that is more consistent for the UI, since we don't mention
"Fleet-managed" anywhere else like ILM, index templates etc.
### Screenshot
<img width="902" alt="Screenshot 2023-12-18 at 16 11 35"
src="d9e54d54-12a2-4031-a51a-e534e40822e3">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Refactoring general ui service to a kbn package.
Resolves an [Appex QA](https://github.com/elastic/appex-qa-team) issue.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This uploads CDN assets to a GCS bucket on commit and after all tests
have passed. This will run on pull requests with `ci:project-deploy-*`
and `ci:build-serverless-image` labels, and on `main`. Assets will
include the first 12 digits of the commit sha as a base path.
Closes#173156
## Summary
This PR adds a `NEW` badge to the profiling tab and changes the
profiling prompt badge color to pink
## Testing
The badges can be checked on the node details page and inside the host
details flyout:
## Summary
PR makes additional changes to Endpoint (kibana) response action APIs in
support of 3rd party EDR systems and support for SentinelOne. Changes
include:
- `release` response action support for SentinelOne
- Action responses for SentinelOne `isolate` and `release` are now
written to the responses index (thanks to [this
PR](https://github.com/elastic/elasticsearch/pull/103555))
- Action Details and List APIs now return `agentType` and support 3rd
party EDR response actions
- SentinelOne response actions are now returned and in the expected
state (completed)
- Added feature usage reporting to response actions client base class
(sent when action request is written to ES index)
- Added method to SentinelOne actions client to retrieve agent details
- Host name for SentinelOne is now stored along with the Action Request
document
- Refactored action details and action list services to use common
methods for:
- fetching the action responses from ES
- building the `ActionDetails` record for each action
- Made several types (mostly around response action responses) to be
generic to provided the ability to narrow the `output` type
Resolves https://github.com/elastic/kibana/issues/173857
## Summary
Updates the size of the input labels for the ES query and index
threshold rules.
It is helpful to hide whitespace when reviewing the code changes.
**KQL**
<img width="618" alt="Screen Shot 2024-01-03 at 10 03 36 AM"
src="0079f54e-d367-43cd-94e4-1004c8351d0a">
**Query DSL**
<img width="615" alt="Screen Shot 2024-01-03 at 10 04 06 AM"
src="60ac7148-7e4e-4be5-bc82-de99e91a5d9e">
**ES|QL**
<img width="616" alt="Screen Shot 2024-01-03 at 10 04 35 AM"
src="bddd3c2b-42eb-43ec-b4f4-76df0138834d">
**Index Threshold**
<img width="617" alt="Screen Shot 2024-01-03 at 10 02 29 AM"
src="afc20b9d-73c6-4f74-bb9d-a980f488cecd">
## Summary
Create the Expandable Host flyout with the risk inputs panel.
<img
src="b7443ca0-c369-4b53-99b4-68810d4adab1"
width="400" />
<img
src="961e37b0-e2bc-48d0-90f3-55226498529c"
width="400" />
### What is included
* Host panel creation
* Left risk inputs panel
* Refactor user panel component to be reused by Host
* Risk score section
### What is not included
* Asset integration section
* Asset criticality
### How to test it?
* Enable experimental flag `newHostDetailsFlyout`
* Create alerts with `host.name` field
* Open the alerts page and click on the `host.name` field
* It should not display the expandable risk input panel
* Enable Risk engine
* make sure it generates data for the host
* Open the flyout once more and check if the expandable risk input panel
opens
---------
Co-authored-by: Tiago Vila Verde <tiago.vilaverde@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/173125
Adds a new `xpack.fleet.isAirGapped` flag to `kibana.yml` that allow
users in air-gapped environments to inform Fleet that it should "fail
fast" and skip unnecessary requests that won't be possible as Kibana
doesn't have internet access.
This PR also uses the new flag to skip the API request to the
`product_versions` API if the airgapped flag is set to true. There are
probably other places we could use this flag in a similar way, but they
can be handled separately from this PR.
### Checklist
Delete any items that are not applicable to this PR.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
closes https://github.com/elastic/kibana/issues/172567
Replace and use ad-hoc data views instead of static ones.
1. Metrics dashboard
2. Discover link
3. Mobile geo map
Metrics tab
ca40c0d7-498c-44a7-80f1-8c225218a7f6
Discover link
376d8f2f-6e6a-482b-a829-9963b7b6eeaf
## Note
it is worth mentioning that when the links open in a new tab discover
app uses the static data view.
68984ebc-41ef-4db6-b554-e87b73d201e6
## Summary
Closes https://github.com/elastic/ingest-dev/issues/2726
Allow upgrade with typing in agent version when agent is on latest
version according to the version list. This is an escape hatch if the
version list does not contain the latest version.
To verify:
- enroll an agent locally or in a vm with latest published version
8.11.3
- check that Upgrade agent action is not disabled in agent list (single
and bulk action) and agent details.
- when opening the upgrade agent modal, the combo box should allow
typing in any version
- the upgrade available badge is hidden when the agent is on the latest
version in the list
<img width="1181" alt="image"
src="d2ada6f1-7659-4442-8bc1-f9d9e7ddc727">
<img width="1201" alt="image"
src="5b2a6ba6-9f63-45b9-a296-a81c60ad2bfd">
<img width="1198" alt="image"
src="c6c9c87b-66ee-4cd7-96f9-27a670ee6ec0">
### 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/168445
We follow the approach:
1. if we can render we are able to save even with errors
2. If we cannot render, we cannot save
There are 3 cases we have to think when approaching this task.
1. When the error comes from the request (for example, incorrect KQL in
'filter by' or wrong response from ES)
We don't catch those cases in Lens app so I didn't fix it here either.
It would be very difficult to do so.
2. When the chart cannot be rendered
(whether there's a missing dimension or errors stop the expression to be
generated)
<img width="524" alt="Screenshot 2023-10-16 at 13 30 32"
src="9ecafcd8-7a70-45b8-babe-ca65bc1e4903">
3. When the chart has errors but can be rendered
We allow saving in this case.
<img width="381" alt="Screenshot 2023-10-17 at 15 02 47"
src="d2358ef7-d7b7-4cbf-8532-0caa60d73008">
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
