## Summary
Updates to unified field list on typing are debounced - this way we
don't get so many updates when typing in the search input.
Flaky test runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6424
## Performance comparison
Test: typing the string: activem for metricbeat data (~6000 fields)
before (costly update on every keystroke):
<img width="669" alt="Screenshot 2024-06-28 at 17 28 38"
src="7075f7bc-2d90-4177-acac-69ac101b2ef1">
after (only one costly update when user stops typing):
<img width="269" alt="Screenshot 2024-06-28 at 17 24 43"
src="8c0ce4a3-7c1a-428b-a482-f6b4d87911e0">
Fixes#174970
Fixes https://github.com/elastic/kibana/issues/186044
## Summary
Migrates the legacy Links embeddable to the React embeddable framework.
Additionally, the new embeddable factory now resolves the dashboards
info prior to rendering the Links component. Prior to this change, the
`DashboardLinkComponent` would be responsible for asynchronously loading
dashboards info and rendering a loading icon. This change reduces the
complexity of the `DashboardLinkComponent` as the resolved state is now
passed in as props.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
This PR is a simple update of our pipeline resource definition files
after the recent bumps.
---------
Co-authored-by: Jonathan Budzenski <jon@elastic.co>
Resolves: #187268
This PR classifies the verification_errors thrown by the Elasticsearch
Query (ES|QL) rules as user error.
## To verify
Create an Elasticsearch Query with ES|QL and use anon-existing field in
the query.
Let the rule run.
`/api/task_manager/metrics?reset=false` should show a user error under
`alerting:__es-query"`
```
"alerting:__es-query":{"success":0,"not_timed_out":1,"total":1,"total_errors":1,"user_errors":1,"framework_errors":0}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow up to https://github.com/elastic/kibana/pull/187064
* Improves the `rollups.test.ts` integration test.
* Adds the `count` field to the mappings, so that it can be aggregated.
This PR aligns the naming of the entity discovery framework components
to the following pattern:
`entities-{schema version}-{history|latest}-{definition ID}` (with a few
differences here and there, the index has a leading dot, some indices
have a date after them).
---------
Co-authored-by: Chris Cowan <chris@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
> [!WARNING]
> Beware - the longest description ever for a one line change is
incoming.
>
>
>
> **TLDR:** We were previously `await`ing the initialization of the
control group before navigating to the destination dashboard, which
caused a race condition where, if the control group had time to report
unsaved changes before the initialization promise was resolved, the
control group's input would get backed up under the wrong ID. If we no
longer `await` control group initialization, we remove this race
condition.
Previously, on dashboard navigation, we were `await`ing the
initialization of the control group before navigating to the destination
dashboard - this was because, before
https://github.com/elastic/kibana/pull/174201, the control group could
change its selections and the dashboard needed to know the most
up-to-date control group output before it could start loading its
panels. However, once https://github.com/elastic/kibana/pull/175146 was
merged and the control group started reporting its own unsaved changes,
this caused a race condition on navigation depending on whether or not
the dashboard had time to backup its unsaved changes to the session
storage before the control group was initialized.
### Description of the race condition
Consider the following repro steps:
1. You start at your source dashboard (which has no controls), clear
your cache, and slow down your network speed.
2. You click on a markdown link to navigate to your destination
dashboard (which has controls).
3. You think everything worked as expected - hoorah!
4. You click on a markdown link to navigate back to your source
dashboard.... but your source dashboard now has the controls of your
destination dashboard! What just happened?
> [!NOTE]
> If the initialization of the control group happens **before the
dashboard has a chance to backup the control group input to session
storage under the wrong ID**, then this bug does not happen - that is
why it is important to slow down the network speed when trying to
reproduce this, and it is also why this bug was more prevalent on Cloud
than local instances of Kibana.
91f9b9e1-87f0-44aa-b596-577dd4a541f9
On step 2 when the markdown link is clicked, this is what happens in the
code:
1. The `navigateToDashboard` method is called.
2. The control group is told to update its input and reinitialize via
the call to `controlGroup.updateInputAndReinitialize` in the
`initializeDashboard` method.
3. The dashboard is `await`ing the initialization of the control group
before proceeding with navigation.
4. The control group is updated, which triggers its `unsavedChanges`
subscription - this is comparing its own state to that of the **source**
dashboard, which is the **wrong** input to be comparing against.
5. The control group reports to the dashboard that it **has** unsaved
changes.
6. The dashboard backs up its unsaved changes to session storage under
the wrong ID since navigation hasn't happened yet - i.e. the
**destination dashboard's** control group input gets backed up under the
**source dashboard's ID**
7. Finally, the control group reports that it is initialized and the
dashboard can proceed with navigation - so, the dashboard ID changes and
its input gets updated.
8. This triggers the control group to **once again** trigger the
`unsavedChanges` subscription - this time, the comparison occurs with
the **proper** dashboard input (i.e. the input from the **destination**
dashboard). Assuming no previous unsaved changes, this would return
**false** (i.e. the control group reports to the dashboard that it has
**no** unsaved changes).
On step 3, that is why the destination dashboard appears as expected -
it has the correct controls, and no unsaved changes. But then, on step
4, this is what happens:
1. The `navigateToDashboard` method is called.
2. We fetch the session storage so that the "unsaved changes" can be
applied to the dashboard saved object
3. Uh oh! As described in step 6 above, the session storage for the
source dashboard includes the control group input from the
**destination** dashboard!
4. So, when you go back to the source, the destination dashboard's
controls come with you 🔥🔥🔥
### Description of the fix
Now, let's instead consider what happens when we **don't** `await` the
control group initialization - if we go back to step 2 of the repro
steps, then this is what happens in the code:
1. The `navigateToDashboard` method is called.
2. The control group is told to update its input and reinitialize via
the call to `controlGroup.updateInputAndReinitialize` in the
`initializeDashboard` method.
3. The dashboard is **not** waiting for initialization, so it goes ahead
with navigation **before** the control group has time to report its
unsaved changes (the control group's unsaved changes subscription is
debounced).
4. Navigation occurs and **nothing** gets backed up to session storage!
That is why, by no longer waiting for the control group to be
initialized on navigation, we are no longer seeing the bug where
controls were getting "replaced" on navigation:
0e45a207-ff2a-46a6-9609-11a8dc5bcf67
### 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)
This PR adds OpenAPI schemas for Defend Workflows API endpoints that
previously didn't have them. Here are the changes made:
1. Added a schema for `/api/endpoint/isolate`, which is deprecated and
now redirects as a `308` to the new path
(`/api/endpoint/action/isolate`). It's tagged with `x-labels` as `ess`
only.
2. Added a schema for `/api/endpoint/unisolate`, which is deprecated and
now redirects as a `308` to the new path
(`/api/endpoint/action/unisolate`). It's tagged with `x-labels` as `ess`
only.
3. Added a schema for
`/api/endpoint/protection_updates_note/{package_policy_id}`.
4. Added `x-labels` field to all existing Defend Workflows API paths for
proper tagging.
For more information on `x-labels`, please refer to
https://github.com/elastic/kibana/pull/184348
## Summary
This PR removes `@timestamp` from the latest index template mappings.
This will help users who explore `.entities-observability.latest-v1.*`
in Discover ES|QL by using the date picker to filter the results.
### Testing
Using the following ES|QL in Discover:
```
FROM .entities-observability.latest-v1.* | LIMIT 10
```
The date picker should look like this:
<img width="932" alt="image"
src="bf75c785-44f6-41b9-b12f-661327012819">
Co-authored-by: Milton Hultgren <milton.hultgren@elastic.co>
## Summary
fix https://github.com/elastic/kibana/issues/187570
The problem was that when the system/browser was in dark mode, the
default text color became white, but the background was forced to a
specific bright color, so the text became unreadable. A quick fix is to
also force the text color (I used EUI text colors)
<img width="858" alt="Screenshot 2024-07-05 at 12 44 11"
src="9ccefc04-60f6-46e3-a649-4e47cad043ac">
This changes the resource names from being stateful to being static.
This makes it easier to import them since they don't have to be passed
around, and "go-to-definition" actually takes you to the implementation
point instead of the types.
## Summary
Ticket https://github.com/elastic/kibana/issues/187384
These changes fix the error on saving the alert
> An error occurred during rule execution: message: "[1:6778] failed to
parse field [kibana.alert.original_event.action] of type [keyword] in
document with id '027b925ae2799635a0dee97a6aa9d58dc87d9771'."
which happens due to not stripping non-ECS compliant sub-fields of the
`event.action` field.
See the main ticket for steps to reproduce the issue.
## Summary
Part of https://github.com/elastic/kibana/issues/186530.
This PR sets the basis for allowing namespaced usage counters.
It relocates `usage-counters` SO type from `.kibana` to a dedicated
`.kibana_usage_counters`.
Furthermore, the original SO type is removed, and replaced by 2 separate
types:
* `server-counters`
* `ui-counters`
Note that these 2 steps are necessary if we want to leverage
`namespaces` property of the saved objects.
We can't currently update the `namespaceType: 'agnostic'` without
causing a migration.
Thus, these two types will be defined as `namespaceType: single`.
Up until now, UI counters were stored under a special `domainId:
uiCounter`.
This forced a workaround that consisted in storing `appName:eventName`
in the `counterName` property of the SO.
Having a dedicated SO type for them allows to store `appName` as
`domainId`, avoiding the need for a
[workaround](https://github.com/elastic/kibana/blob/main/src/plugins/usage_collection/common/ui_counters.ts).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In rare cases when the list of continuous transform exceeds the allowed
URL length, we fetch stats for all transforms.
The elasticsearch client has `transform-id` param as optional, but we
actually have to pass `_all` or `*`. This PR sets the `transform_id`
param explicitly in this case.
### 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 moves the definitions of the following pipelines from
`catalog-info.yaml` to `.buildkite/pipeline-resource-definitions`:
- `buildkite-pipeline-kibana-emergency-release` ->
`.buildkite/pipeline-resource-definitions/kibana-serverless-emergency-release.yml`
- `kibana-tests-pipeline` ->
`.buildkite/pipeline-resource-definitions/kibana-serverless-quality-gates.yml`
More details in the original PR #186833, which is split into the
creation of the new pipeline (#187251) and moving existing pipelines
from catalog-info.yaml to .buildkite/pipeline-resource-definitions (this
PR).
This PR does three things:
* Try to download agent from the central repository (expected to fail
for now as 8.15.0 agent isn't released yet
* Adjust snippet to also set up local data dir correctly
* Update k8s manifest via
https://github.com/elastic/opentelemetry-dev/pull/299
## Summary
This PR is to address Flaky API FTR test for Benchmark API.
This flakiness is being caused by the function that we used on the FTR
have a possibility to return undefined value.
To address this issue, we will kept retrying the function in case it
returns undefined for maximum amount of 10 times
Update:
After a discussion, I think its better to change this test to only use 1
Rules instead of 2 when calculating the posture, the reason being is
that this flakiness where sometimes it only returns only 1 rule is
causing too much problem and too much time to figure out the reason.
We should also add an integration test that would test this scenario
where we are using 2 rules (separate Ticket)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We have been asked to stop using the `second quality gate` terminology
in favor of `kibana QA quality gate`. This PR updates the readmes to
reflect the new changes.
**‼️ DO NOT MERGE UNTIL 8.15 IS CUT**
## Summary
Part of https://github.com/elastic/kibana/issues/171425.
This PR allows parsed KQL expressions that don't have a key/field. For
example, the follow query expressions are now allowed when searching
agents:
```
last_checkin_message.keyword : "Running" and Development
```
```
macbook
```
```
"8.15.0" and tags : "Development"
```
This PR also:
* Enables the flag `enableStrictKQLValidation` now that both free-form
text expressions are allowed and validation remains on expressions which
specify a field
* Syncs the maintained agent mappings used for populating suggestions
with the [real mappings in
ES](248b045d70/x-pack/plugin/core/template-resources/src/main/resources/fleet-agents.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
