## Summary
This PR originally aimed at replacing the usages `styled-components`
with `@emotion/react` in the
`security_solution/public/common/components/events_viewer` folder. I
quickly realized removing some of these would require a small refactor.
This lead to making a few more changes, as many properties were actually
unused so a cleanup was welcome.
Only 2 small UI changes are introduced in this PR:
- the inspect icon on the top right corner of the tables are now always
visible instead of only visible on hover. I'm aware that this is a
different behavior from the alerts table in the alerts page, but we also
have other tables (like the one on threat intelligence page) where the
icon is always shown. Waiting on @codearos for confirmation here
- the `Grid view` and `Additional filters` button are reversed due to
the simplification of the code
No other UI changes are introduced. No behavior logic has been changed
either.
The biggest code cleanup are:
- removal of a bunch of unused properties and logic
- deletion of the RightTopMenu component: it was used in both
`StatefulEventsViewerComponent` and `getPersistentControlsHook` but none
of the internal logic was overlapping. I don't know how we got there but
its current implementation was overly complex and completely
unnecessary...
#### Alerts page
#### Rule creation page
#### Host/User/Network events tab
#### Host session view tab
### 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>
**Partially addresses:** https://github.com/elastic/kibana/issues/202715
## Summary
This PR adds React error boundaries to comparison side, final side readonly and final side edit modes. The goal is mitigating chances of blocking rule upgrade workflow.
## Details
Kibana already has `KibanaErrorBoundary` component to catch thrown errors. Closer look at the component reveals it was designed to be applied at page level. The component doesn't accept any customization.
Obviously Kibana requires an error boundary component to catch thrown errors at section levels. Such error are usually fatal non-recoverable error happening due to unexpected data arrives from the storage. It may block critical workflows.
To mitigate workflow blocking and address section level errors a new `KibanaSectionErrorBoundary` component was added. It accepts `sectionName` property to properly reflect it in messages. On top of that it shared displaying error functionality with `KibanaErrorBoundary`.
`KibanaSectionErrorBoundary` was applied to the following sections in Rule Upgrade Flyout
- All flyout tabs
- comparison side (Diff View)
- final side readonly mode
- final side edit mode
## Screenshots
**Before:**
**After:**
<img width="2549" alt="Screenshot 2025-01-02 at 12 26 15" src="https://github.com/user-attachments/assets/3617be5b-c063-4529-9b7f-e931520fbf92" />
<img width="2557" alt="Screenshot 2025-01-02 at 12 24 33" src="https://github.com/user-attachments/assets/da7407af-a263-4e4a-812e-6b76a75b5be9" />
<img width="2556" alt="Screenshot 2025-01-02 at 12 26 57" src="https://github.com/user-attachments/assets/c2faedbe-15a5-4da6-9c9a-a767edb403b0" />
<img width="2556" alt="Screenshot 2025-01-02 at 12 27 08" src="https://github.com/user-attachments/assets/061dd645-f5e4-48ac-957b-50a8fea2d2e7" />
<img width="2556" alt="Screenshot 2025-01-02 at 12 27 27" src="https://github.com/user-attachments/assets/3e8c31de-d251-4eb1-a49f-8622b5640b70" />
## How to test?
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled
- Allow internal APIs via adding `server.restrictInternalApis: false` to `kibana.dev.yaml`
- Clear Elasticsearch data
- Run Elasticsearch and Kibana locally (do not open Kibana in a web browser)
- Install an outdated version of the `security_detection_engine` Fleet package
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"force":true}' http://localhost:5601/kbn/api/fleet/epm/packages/security_detection_engine/8.14.1
```
- Install prebuilt rules
```bash
curl -X POST --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 1" -d '{"mode":"ALL_RULES"}' http://localhost:5601/kbn/internal/detection_engine/prebuilt_rules/installation/_perform
```
- Cause some error in the rule upgrade flyout, for example set a negative look-back duration for `Suspicious File Creation via Kworker` rule by patching the rule
```bash
curl -X PATCH --user elastic:changeme -H "Content-Type: application/json" -H "elastic-api-version: 2023-10-31" -H "kbn-xsrf: 123" -d '{"rule_id":"ae343298-97bc-47bc-9ea2-5f2ad831c16e","interval":"10m","from":"now-5m","to":"now-2m"}' http://localhost:5601/kbn/api/detection_engine/rules
```
- Open rule upgrade flyout for `Suspicious File Creation via Kworker` rule
## Summary
It fixes#205051
<del>
Files are excluded because of `euiScrollBar` and `euiScrollBarCorner`
replacement (TBD)
-
x-pack/solutions/observability/plugins/exploratory_view/public/components/shared/exploratory_view/series_editor/series_editor.tsx
-
x-pack/solutions/observability/plugins/exploratory_view/public/components/shared/exploratory_view/series_editor/components/filter_values_list.tsx
</del>
✅ DONE
## Summary
In this PR we are wrapping the `Chart` component in `EuiErrorBoundary`
to prevent getting a full screen error because some of the charts fail
in the Service Overview screen.
This is now needed because of the [update of `@elastic/charts` from
68.0.4 to 68.1.0](https://github.com/elastic/kibana/pull/206497).
|Before|After|
|-|-|
|||
>[!IMPORTANT]
>This PR will be followed by another to properly address the error
triggered by the charts. For now, we need this one to silence the
failing Cypress tests in some CI runs and ensure that at least the
functioning charts are displayed on the screen.
Resolves https://github.com/elastic/kibana/issues/205970
Updates logic to account for knowledge base `/setup` no longer polling
for model readiness before returning.
- Currently we only poll `/status` if user manually installs the
knowledge base. In cases where we auto installed, such as after
successfully setting up a connector, we depended on `/setup` to poll
internally. Since the latter was removed, we need to always poll
`/status`, otherwise user could potentially be in the state where
`setup` has finished (considered installed) but `status` still reports
not ready and we show the install message again (see screenshots in
https://github.com/elastic/kibana/issues/205970)
- Currently if an install is in progress and user closes the flyout, the
progress state is lost. These changes should continue to reflect the
installation progress in the UI.
- Renames variables and adds comments for easier readability
- adds unit test to component that handles the install UI state,
`WelcomeMessageKnowledgeBase`
---------
Co-authored-by: Søren Louv-Jansen <sorenlouv@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/206599
This PR aims to fix a flaky test that waits for `aria-selected`
attribute to be `true` after click, but it resolved to `false`.
The test was written like this:
````
cy.getByTestSubj('apmAppVersionTab').click().should('have.attr', 'aria-selected', 'true');
````
After some research, I found that having it like that makes Cypress skip
waiting for any visual or state changes after the click. This can lead
to scenarios where the attribute hasn't been updated yet by the time the
expectation is evaluated.
By separating the click and the assertion, we effectively allow more
time for the state to update, and Cypress will automatically retry it
within the configured timeout.
## Summary
Part of #178606.
Uses `dataViews.getFieldsForIndexPattern()` instead of custom code to
identify populated fields for field stats and the data grid used in the
Data Frame Analytics wizard.
- The previous custom code supported abort signals to cancel requests as
well as runtime fields. This was not yet supported by
`getFieldsForIndexPattern/getFieldsForWildcard`, so this PR adds that
capability.
- This also tweaks the options interface for `getFieldsForIndexPattern`
so you no longer have to pass in the empty `pattern: ''`.
This GIF demonstrates cancelling the request by navigating away from the
Data Frame Analytics wizard while the page is still loading (done with
3G throttling in dev tools):
### 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] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/200858
Main goal of this PR is to introduce initial autocomplete for the `JOIN`
command:
In this PR:
- Adds `JOIN` command and `AS` function definition
- Adds `JOIN` command validation
- Adds `JOIN` command autocomplete
- New command suggestion, including command type
- Command suggestion on partial command entry
- Suggests lookup indices
- Fetches them from the server and caches
- Also suggests lookup index aliases
- Suggests `ON` keyword
- Suggests join condition fields
- Suggests `,` or `|` after join condition fields
- Autocomplete behaviour that could be improve in followup
- After index suggestion selection, the "ON" suggestion does not appear
automatically, user needs to enter space ` `.
- When suggesting `ON <condition>` fields, compute lookup index and
source index field intersection and show only those.
- Only `LOOKUP JOIN` is exposed. `LEFT JOIN` and `RIGTH JOIN` are
defined in code, but commented out.
- The aliasing using `AS` operator will validate, but autocomplete does
not actively suggest it to the user.
---
### Testing
To test, you can create lookup indices in dev console using the
following queries:
```
PUT /lookup_index
{
"settings": {
"index.mode": "lookup"
},
"mappings": {
"properties": {
"currency": {
"type": "keyword"
}
}
}
}
PUT /lookup_index_with_alias
{
"settings": {
"index.mode": "lookup"
},
"aliases": {
"lookup_index2_alias1": {},
"lookup_index2_alias2": {}
}
}
```
Add some sample data:
```
POST /lookup_index/_doc
{
"currency": "EUR",
"continenet": "Europe",
"name": "Euro"
}
POST /lookup_index/_doc
{
"currency": "USD",
"continenet": "North America",
"name": "US Dollar"
}
POST /lookup_index/_doc
{
"currency": "USD",
"continenet": "North America",
"name": "Canadian Dollar"
}
```
Add `kibana_sample_data_ecommerce` sample data and execute a query:
```
FROM kibana_sample_data_ecommerce | LOOKUP JOIN lookup_index ON currency
```
---
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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>
## Summary
It fixes#191179
It fixes#202493
By adding guard rail to limit the time range to "no more than" 3 times
the execution window. As proposed
[here](https://github.com/elastic/kibana/issues/191179#issuecomment-2501435071)
While ensuring the rule will still be able to detect the missing groups.
### What has been done:
- Fix the unlimited extension of the time range when the rule fails for
both rules, the Metric and Custom Threshold
- Tests have been added to cover the guardrail
### Hot to test the PR:
- Create Metric and Threshold rules that fire alerts with a groupBy
options, e.g., with `host.name`
- From the data source/generation tool, try to remove groups, and the
rule should be able to detect the missing groups.
- Try to make the rule fail e.g., a typo in the rules' executors.
- The rule time range would be extended up to 3x during the execution
and then back to the defined time range.
### Why not ignore the `lastPeriodEnd` without using a guardrail
This feature is implemented for a reason, which is to catch the missing
groups and keep the rule on-sync as much as possible. Also, the Security
team has an appetite to introduce a similar feature.
Instead of removing it completely, we keep it with a guardrail to
protect the cluster resources. And we can go back to remove it or update
it anytime in the future.
<img width="1433" alt="Screenshot 2024-11-28 at 11 57 13"
src="https://github.com/user-attachments/assets/72a04b25-c7c6-4261-8fea-9fa9a1cce3a6">
<img width="1427" alt="Screenshot 2024-11-28 at 11 57 06"
src="https://github.com/user-attachments/assets/e0ee8605-fe27-4f23-bf42-4b6a9fe76e2b">
Fixes https://github.com/elastic/kibana/issues/206275
There was an issue with Case Page header not updating correctly when
navigating directly from one case to another (through similar cases
feature).
The solution for that was to add a key to the Route component for the
case view, but it is suboptimal - all the components on that page would
end up being re-rendered.
Thats why this PR moves the key to the header itself, with the same
result effectively but without re-rendering the entire page.
## Summary
This deprecation was added to the 8.x branch in
https://github.com/elastic/kibana/pull/202775 but I think we also need a
record of this breaking chain on `main`
---------
Co-authored-by: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com>
Migrates the `.kibana_streams` index to be managed by the Storage Index
Adapter.
Additionally, `streams_crud` was refactored into a client that can be
used in routes (and at some point, other plugins).
Functional changes:
- The defaults for the types were removed. Setting defaults means that
we have to use `.parse()` everywhere to make sure we get the default
values. Without using parse, the current type guards make it seem like
the defaults have been added to a value.
- The storage adapter was simplified (no more enums, required or
multi-value until we need it)
- Write access is verified before deleting a stream
- We throw an error if an update from ingest -> wired or vice versa is
attempted
Notes:
- I changed `readStream` to `getStream` to avoid confusion around
`ReadStreamDefinition` and `readStream`. This was before I realized that
ReadStreamDefinition refers to the value returned from the `GET
/api/streams/{id}` endpoint. I've left this change in place for now as I
would consider `get` to be more commonly used verbiage (eg.
`esClient.get`), but happy to revert.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Closes#203740
## Summary
After some other attempts to fix it, I saw that a different tab was
selected before the test started so I added an extra step to start from
the overview (this should make it more stable- locally it passed several
times so I guess the issue was that other test results affected the
test)
Closes https://github.com/elastic/kibana/issues/192891
### Summary
The element wasn't found in the DOM because was reloaded, found the
error `StaleElementReferenceError: stale element reference: stale
element not found in the current frame`, the test has been fixed adding
a wait for the page to completely load.
Going to run flaky test runner
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[@types/diff](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/diff)
([source](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/diff))
| devDependencies | major | [`^6.0.0` ->
`^7.0.0`](https://renovatebot.com/diffs/npm/@types%2fdiff/6.0.0/7.0.0) |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkRhdGFEaXNjb3ZlcnkiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `eef54b3` ->
`f2813ac` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Add `load_attack_discovery_data` script that populates alerts data for
Attack discovery testing
To load Attack discovery data to the existing instance:
```
node x-pack/solutions/security/plugins/security_solution/scripts/load_attack_discovery_data.js --kibanaUrl http://127.0.0.1:5620 --elasticsearchUrl http://127.0.0.1:9220
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
## Summary
Closes#197731
- Using the new `audit_unenroll_reason`, added `Orphaned` and
`Uninstalled` Badges to the table UI to make those entries distinct from
the normal `offline` entries
- Added conditional rendering on the labels at the top of the table to
only show up when the matches are greater than zero
- Updated `offline` counts to be distinct from the `orphaned` and
`uninstalled` items in those labels
- Added Orphaned and Uninstalled filters to status filter dropdown
Screenshot of new:
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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/src/platform/packages/shared/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
- [ ] [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
- [ ] 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 was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
n/a
## Release Note
Improves filtering & visibility of `Uninstalled` and `Orphaned` Agents
in Fleet, by differentiating them from `Offline` agents. Status filters
have been added for both `Uninstalled` and `Orphaned` agents. Agent
`status` runtime field has been updated to return accordingly when an
agent is `uninstalled` or `orphaned`. Additionally, improved UI by
hiding agent labels with `0` agent matches.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Elasticsearch is introducing a breaking change in `8.18` and `9.0.0` to
`semantic_text` fields.
This PR ensures compatibility with this new `semantic_text` format.
Relates to https://github.com/elastic/dev/issues/2936
### Changes made
- Remove the `inference` meta field exclusions in recalling from
semantic search connectors (the `inference` subfield won't be returned
anymore with the new `semantic_text` format)
- Set the `index.mapping.semantic_text.use_legacy_format` index setting
to false to force the new format for KB indices and evaluation framework
indices.
The following does not impact Obs AI Assistant as a part of this
breaking change:
| Breaking change | Do we use it? | Is there an impact? |
|--------|--------|--------|
| `inner_hits` is removed and `highlight is introduced | We don't use
`inner_hits` at the moment | No |
| The shape of semantic text field return type is updated to a string
(previously it was an object with a `text` property) | Even though we
query via the `semantic_text` field in KB entries, we don't use the
result of the `semantic_text` field in `_source` | No |
| pre-computed embeddings using a new `_inference_fields` metafield |
Not used | No |
### 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] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
