closes [#189064](https://github.com/elastic/kibana/issues/189064)
## Summary
This PR changes Lens embeddable to support creating custom error
messages by using the new `customBadgeMessages` prop.
<img width="500px" alt="image"
src="https://github.com/user-attachments/assets/d48d86fa-b4a7-4dd5-ad84-9fe4bf144672">
The custom error message will only be displayed in the context of the
hosts view and asset details, which is where this new prop is being
used. Everywhere else will display the default error handling provided
by Lens
<img width="500px" alt="image"
src="https://github.com/user-attachments/assets/38ecaee9-5f25-4d34-85e4-f176095982c5">
### How to test
- Start a local kibana and es instances
- Run `node scripts/synthtrace infra_hosts_with_apm_hosts --live`
- Change the the index patter in Settings to `metrics-apm`
- Navigate to Infrastructure > Hosts View and open the asset details
flyout
- The missing field message should be displayed as the screenshot above
- Open a chart in lens
- The default Lens message will be shown
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Related to https://github.com/elastic/kibana/issues/189091
This PR decouples the NotesWidget and EsqlWidget from the previous
AddWidgetUI, so we can have them both on the page. It's a step forward
the expected design. There is some missing element, like the
visualization selector which I'll add later.
I've also removed the global kuery filter as it is not on the design.
Things not implemented in this PR:
- edit widget
- date range filter (using default 15min from the page)
- lot of cleanup of unused feature
Screenshots |
-- |
Testing:
- Run some data forge scripts: `node x-pack/scripts/data_forge.js
--events-per-cycle 50 --lookback now-3d --dataset fake_stack
--install-kibana-assets --kibana-url http://localhost:5601/kibana`
- Go to http://localhost:5601/kibana/app/investigate/new#/
- Create an observation chart based on this esql query: `FROM
kbn-data-forge-fake_stack.admin-console-* | keep @timestamp,
http.response.* | LIMIT 103`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Panagiota Mitsopoulou <panagiota.mitsopoulou@elastic.co>
## Hide manual rule run behind feature flag for bulk actions
Currently it exposes on serverless, but user can't run it still. We are
waiting for docs, to remove FF
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/163981
The Dashboard and Panel Settings Flyouts already seem to be fixed but
the Controls Settings Flyout did not specify the maxWidth.
The drilldown (manage and create) flyouts did not have a maxWidth
specified but based on main, it seems to match medium. To avoid any
unclearness, I have added the maxWidth property to the flyout.
The edit and create drilldowns that didn't have specified maxWidths can
be toggled to each other so they should be the same. I think there can
be a little bit of a debate on which makes the most sense. Although
there is some white space to the right of the buttons in the create
drilldown I think it makes the most sense for the manage drilldowns to
not be cramped and have the maxWidths be medium if possible.
<img width="900" alt="Screenshot 2024-07-24 at 1 19 51 PM"
src="https://github.com/user-attachments/assets/549c34df-5d85-40f4-bfb4-dd5d17d96ca5">
### Edit drilldown
Size s makes it look more cramped and breaks the word Discover onto two
lines:
<img width="626" alt="Screenshot 2024-07-24 at 1 15 09 PM"
src="https://github.com/user-attachments/assets/89013146-f437-4180-8de0-12d033198b88">
Size m
<img width="1044" alt="Screenshot 2024-07-24 at 1 09 35 PM"
src="https://github.com/user-attachments/assets/60dd3838-724a-42c4-b717-c2d7e75a3c10">
### Create drilldown:
I'm leaning towards size 's' for the create drilldown flyout based on
the following screenshots:
Size s
<img width="631" alt="Screenshot 2024-07-24 at 1 12 46 PM"
src="https://github.com/user-attachments/assets/7e052bbf-3d02-492e-9332-8998b01c95b7">
Size m
<img width="710" alt="Screenshot 2024-07-24 at 1 10 58 PM"
src="https://github.com/user-attachments/assets/6f35ee9c-5858-400d-9498-c90323f44303">
## Summary
Adds Amazon Bedrock support to the [Inference Endpoints management
UI](https://github.com/elastic/kibana/pull/186206)
(`relevance/inference_endpoints`) management list view.
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Adding generic support for experimental features in timelines
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Similar to how APM is shown as an integration as well, show the new
OTel-based flow on the integrations page so people find it from there as
well:
<img width="991" alt="Screenshot 2024-07-25 at 11 32 46"
src="https://github.com/user-attachments/assets/4d806ed1-4b01-4ac8-985c-0e59708fa4c6">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Related to #183220
## Summary
This PR saves ECS groups in the Alert As Data (AAD) document for the log
threshold and SLO burn rate rules.
|Rule|AAD document|
|---|---|
|SLO burn
rate||
|Log
threshold||
### 🧪 How to test
- Create a log threshold and SLO burn rate rule with multiple groups
(both ECS and non-ECS fields)
- Check the related AAD document; you should be able to see the ECS
fields at the root level and not see non-ECS fields there
- Check the same information for the recovered alerts
- Rules without group by should work as before
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves#188643Resolves#188644Resolves#188630
## Summary
Various fixes for Quickstart Onboarding flows
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Followup to https://github.com/elastic/kibana/pull/187999
## Summary
Dynamically set capacity for cloud deployments if claim strategy is
`mget`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR aims to improve `context.page_name` within stack telemetry.
After the changes we will start seeing information about dataset quality
in `application:management:data_quality` rather than just a generic
pageName such as `application:management`.
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/d172353a-824d-46f7-8d5e-7c564375827a">
**Addresses**: https://github.com/elastic/kibana/issues/184428
## Summary
This PR adds scripts for automatic bundling of Endpoint Management API OpenAPI specs as a part of PR pipeline. Corresponding result bundles are automatically committed to the Security Solution plugin `x-pack/plugins/security_solution` in the `docs/openapi/ess/` and `docs/openapi/serverless` folders (similar to https://github.com/elastic/kibana/pull/186384).
## Summary
This adds an error callout to the index pages in Search if the mappings
contain a semantic text field that references a non-existent inference
ID, or an inference ID without a model that has started.
## Summary
Closes https://github.com/elastic/kibana/issues/187587
This PR changes how the dashboard panel selection items get computed, it
had previously been computed eagerly, in this implementation panel
selection items would only be computed when the user actually clicks the
`add panel` button, with it's results cached so that subsequent
interactions with the `add panel` button leverages the already computed
data.
**Notable Mention:**
The options presented as the dashboard panel list now only comprise of
uiActions specifically registered with the uiAction trigger
`ADD_PANEL_TRIGGER` and specific dashboard visualisation types. See
https://github.com/elastic/kibana/pull/187797#discussion_r1681320456 to
follow the reasoning behind this.
That been said adding new panels to the dashboard, would be something
along the following lines;
```ts
import { ADD_PANEL_TRIGGER } from '@kbn/ui-actions-plugin/public';
uiActions.attachAction(ADD_PANEL_TRIGGER, <registredActionId>);
// alternatively
// uiActions.addTriggerAction(ADD_PANEL_TRIGGER, ...someActionDefintion);
````
### Visuals
7c029a64-2cd8-4e3e-af5a-44b6788faa45
### How to test
- Navigate to a dashboard of choice
- Slow down your network speed using your browser dev tools, refresh
your dashboard, and click on the “Add panel” button as soon as it is
available (before the panels have a chance to load).
- You should be presented with a loading indicator, that eventually is
swapped out for the list of panels available for selection.
### 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)
- [ ]
[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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
<!--
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
-->
Resolves https://github.com/elastic/kibana/issues/189112
## Summary
Adds a mapping to the alerting rule type registry to manage rule types
with a custom task cost and register appropriately. Adds an integration
test to task manager so we can be alerted to task types that register
with non-normal task costs.
## Summary
In order to begin work for encryption key rotation in serverless, we
will need to expose the endpoint use to bulk re-encrypt saved objects.
This endpoint was previously unregistered in serverless. This PR
registers the API and marks it as internal when a serverless build
flavor is detected.
### Tests
-
x-pack/test_serverless/api_integration/test_suites/common/platform_security/encrypted_saved_objects.ts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
In https://github.com/elastic/kibana/pull/188410 we moved history and
latest index templates from global scope to definition scope. The
definition-scoped templates have a wide pattern that would grep any
other definition template already installed and throw the following
error because of conflicting priority. This change narrows down the
index patterns defined in the templates to only grep the ones from the
installed definition
```
{
"statusCode": 500,
"error": "Internal Server Error",
"message": """[illegal_argument_exception
Root causes:
illegal_argument_exception: index template [entities_v1_history_admin-console-services_index_template] has index patterns [.entities.v1.history.*] matching patterns from existing templates [entities_v1_history_builtin_services_from_ecs_data_index_template] with patterns (entities_v1_history_builtin_services_from_ecs_data_index_template => [.entities.v1.history.*]) that have the same priority [200], multiple index templates may not match during index creation, please use a different priority]: index template [entities_v1_history_admin-console-services_index_template] has index patterns [.entities.v1.history.*] matching patterns from existing templates [entities_v1_history_builtin_services_from_ecs_data_index_template] with patterns (entities_v1_history_builtin_services_from_ecs_data_index_template => [.entities.v1.history.*]) that have the same priority [200], multiple index templates may not match during index creation, please use a different priority"""
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is a small refactor of the styled panels in analyzer. Lifted the
wrapper up to the resolver level so that the panels can be reused
without styling. No UI change to the analyzer.
Added force to click since the parent of the element `timelines.cy.ts`
is supposed to click received `pointer-events: none` style and Cypress
is no longer able to click it without `force()`.
closes https://github.com/elastic/kibana/issues/189136
This PR updates the invalid ecs check to include a check for 'reserved'
ECS fields. Reserved ECS fields are valid ecs fields, but ones we do not
want to add mappings for as they are reserved for agent operations or
utilized in categorization.
ECS reserved:
- ecs.version
- error.message
- event.category
- event.created
- event.dataset
- event.ingested
- event.original
- event.type
**Resolves:** https://github.com/elastic/kibana/issues/188817
## Summary
This PR adds automatic shared components conflict resolution functionality for OpenAPI merger. It boils down to a similar result as `npx @redocly/cli join --prefix-components-with-info-prop title` produces by prefixing shared components with document's title in each source.
OpenAPI bundler intentionally won't solve conflicts automatically since it's focused on bundling domain APIs where conflicts are usually indicators of upstream problems.
## Details
While working with various OpenAPI specs it may happen that different specs use exactly the same name for some shared components but different definitions. It must be avoided inside one API domain but it's a usual situation when merging OpenAPI specs of different API domains. For example domains may define a shared `Id` or `404Response` schemas where `Id` is a string in one domain and a number in another.
OpenAPI merger implemented in https://github.com/elastic/kibana/pull/188110 and OpenAPI bundler implemented in https://github.com/elastic/kibana/pull/171526 do not solve shared components related conflicts automatically. It works perfectly for a single API domain forcing engineers choosing shared schema names carefully.
This PR adds automatic shared components conflict resolution for OpenAPI merger. It prefixes shared component names with a normalized document's title.
OpenAPI bundler intentionally won't solve conflicts automatically since it's focused on bundling domain APIs where conflicts are usually indicators of upstream problems.
## Example
Consider two following OpenAPI specs each defining local `MySchema`
**spec1.schema.yaml**
```yaml
openapi: 3.0.3
info:
title: My endpoint
version: '2023-10-31'
paths:
/api/some_api:
get:
operationId: MyEndpointGet
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/MySchema'
components:
schemas:
MySchema:
type: string
enum:
- value1
```
**spec2.schema.yaml**
```yaml
openapi: 3.0.3
info:
title: My another endpoint
version: '2023-10-31'
paths:
/api/another_api:
get:
operationId: MyAnotherEndpointGet
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/MySchema'
components:
schemas:
MySchema:
type: number
```
and a script to merge them
```js
require('../../src/setup_node_env');
const { resolve } = require('path');
const { merge } = require('@kbn/openapi-bundler');
const { REPO_ROOT } = require('@kbn/repo-info');
(async () => {
await merge({
sourceGlobs: [
`${REPO_ROOT}/oas_docs/spec1.schema.yaml`,
`${REPO_ROOT}/oas_docs/spec2.schema.yaml`,
],
outputFilePath: resolve(`${REPO_ROOT}/oas_docs/merged.yaml`),
options: {
mergedSpecInfo: {
title: 'Merge result',
version: 'my version',
},
},
});
})();
```
will be merged successfully to
**merged.yaml**
```yaml
openapi: 3.0.3
info:
title: Merge result
version: 'my version'
paths:
/api/another_api:
get:
operationId: MyAnotherEndpointGet
responses:
'200':
content:
application/json; Elastic-Api-Version=2023-10-31:
schema:
$ref: '#/components/schemas/My_another_endpoint_MySchema'
/api/some_api:
get:
operationId: MyEndpointGet
responses:
'200':
content:
application/json; Elastic-Api-Version=2023-10-31:
schema:
$ref: '#/components/schemas/My_endpoint_MySchema'
components:
schemas:
My_another_endpoint_MySchema:
type: number
My_endpoint_MySchema:
enum:
- value1
type: string
```
Fixes https://github.com/elastic/integrations/issues/9934
## Summary
From the package policies API it is currently possible to get into a
state where one input is enabled while all its streams are disabled.
This can cause issue with data ingestion etc (see above ticket). Note
that the UI prevents this case from happening.
This PR adds a function to packagePolicies `create` and `update`
handlers that forces `input.enabled = false` when all its streams are
disabled, since an input with no enabled streams is functionally useless
anyway.
A previous version of this PR was doing a validation on the endpoints
but this would introduce a breaking change for some users, so it was
decided to do a forced change to the policy instead.
### Testing
Using cloudwatch integration as an example
### Create a new policy
- Install an integration trough the API that has one input enabled with
all its streams disabled
<details>
<summary>See POST request</summary>
```
POST kbn:/api/fleet/package_policies
{
"name": "aws-1",
"description": "",
"namespace": "",
"policy_ids": [
"agent-default-policy"
],
"enabled": true,
"inputs": [
{
"type": "aws-cloudwatch",
"policy_template": "cloudwatch",
"enabled": true,
"streams": [
{
"enabled": false,
"data_stream": {
"type": "logs",
"dataset": "aws.cloudwatch_logs"
},
"vars": {
"log_group_arn": {
"type": "text"
},
"log_group_name": {
"type": "text"
},
"log_group_name_prefix": {
"type": "text"
},
"region_name": {
"type": "text"
},
"log_streams": {
"value": [],
"type": "text"
},
"log_stream_prefix": {
"type": "text"
},
"start_position": {
"value": "beginning",
"type": "text"
},
"scan_frequency": {
"value": "1m",
"type": "text"
},
"api_timeput": {
"value": "120s",
"type": "text"
},
"api_sleep": {
"value": "200ms",
"type": "text"
},
"latency": {
"type": "text"
},
"number_of_workers": {
"type": "integer"
},
"tags": {
"value": [
"forwarded",
"aws-cloudwatch-logs"
],
"type": "text"
},
"processors": {
"type": "yaml"
},
"preserve_original_event": {
"value": false,
"type": "bool"
},
"data_stream.dataset": {
"value": "generic",
"type": "text"
}
}
}
]
}
],
"package": {
"name": "aws",
"title": "AWS",
"version": "2.21.0"
},
"vars": {
"shared_credential_file": {
"type": "text"
},
"credential_profile_name": {
"type": "text"
},
"access_key_id": {
"type": "password"
},
"secret_access_key": {
"type": "password"
},
"session_token": {
"type": "password"
},
"role_arn": {
"type": "text"
},
"default_region": {
"value": "",
"type": "text"
},
"proxy_url": {
"type": "text"
}
},
"force": false
}
```
</details>
The request should succeed and the whole input should be disabled as a
result.
- Repeat the test with the update endpoint, you need to grab the policy
id
```
PUT kbn:/api/fleet/package_policies/84ede2c9-80a0-4f01-b353-0f8ef873faaf
{
"inputs": [
{
"type": "aws-cloudwatch",
"policy_template": "cloudwatch",
"enabled": true,
"streams": [
{
"enabled": false,
"data_stream": {
"type": "logs",
"dataset": "aws.cloudwatch_logs"
}
}
]
}
]
}
```
This request should succeed again and the he whole input should be
disabled again.
### Checklist
- [ ] [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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
