## Summary
The test should verify if a timezone that falls under UTC offset can
correctly transform a formBased lens configuation to an ESQL query.
Unfortunately the choosen timezone (Europe/London) falls under UTC only
when not in DST.
I've selected one of the few countries that falls under UTC all year
round to have this test pass correctly independently on when it is
executed.
## Summary
This PR adds the KPI charts section to the alert summary page. The 3
charts are similar to the ones in the alerts page, but there are some
subtle differences, which lead to one of them being a separate
component, while the other 2 I was able to reuse the existing components
and just add a property to handle the different logic.
Here are the differences:
- in the AI for SOC we do not (currently) have cell actions, so a
property was added to the charts to be able to hide the cell actions
entirely
- the title of the right chart as well as the fact that it does not have
a dropdown to select the field to group the alerts by meant that a new
component (still using existing child components) was created
The charts react to changes to the KQL bar:
https://github.com/user-attachments/assets/ed0e8f14-ba66-46ae-94df-6c8064c7a648
### Notes
Compared to the mocks (link at the end of the PR description), it was
decided to not add the icons to the left of the next for the middle and
right chart of the KPI section. These might be added in the future, but
there is some complexity related to fetching them (especially for the
alert by host) and more thoughts need to be had to make sure we're
handling all the possible cases.
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
And this to generate data: `yarn test:generate:serverless-dev`
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### Notes
You'll need to either have some AI for SOC integrations installed, or
more easily you can:
- change the `alert_summary.tsx` line `38` from `if
(installedPackages.length === 0) {` to `if (installedPackages.length >
0) {` to force the wrapper component to render
- update `42` of the same `alert_summary.tsx` file from `return <Wrapper
packages={installedPackages} />;` to `return <Wrapper
packages={availablePackages} />;` to be able to see some packages
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [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
Mocks:
https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-70999&m=dev
Ticket: https://github.com/elastic/security-team/issues/11958
## Summary
Ref: https://github.com/elastic/kibana/issues/209024
Flake caused by occasionally hitting max signals on the "good" shard and
never triggering the error from the runtime field on the "bad" shard. By
moving the bad runtime field to the `packetbeat` index and changing the
rule query in the test to an `and` we can ensure the rule queries both
good and bad shards.
### Checklist
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
Resolves https://github.com/elastic/kibana/issues/194701
## Summary
The rule conditions are testing that the doc count > -1 but we're
testing that the evaluated value is > 0. Because an evaluated value of 0
will also match the rule condition, occasionally this expect would fail.
Updated the test to match what is allowed by the rule condition.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
`100.0.0` ⏩ `101.0.1`
[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)
## Package updates
### `@elastic/eui`
[`v101.0.1`](https://github.com/elastic/eui/releases/v101.0.1)
- Updated `EuiProvider` and `EuiThemeProvider` with a new
`highContrastMode` ([#8444](https://github.com/elastic/eui/pull/8444))
- This prop allows toggling a higher contrast visual style that
primarily affects borders and shadows
- On `EuiProvider`, if the `highContrastMode` prop is not passed, this
setting will inherit from the user's OS/system settings
- If the user is using a forced colors mode (e.g. Windows' high contrast
themes), this system setting will take precedence over any
`highContrastMode` or `colorMode` props passed
- Added `highContrastModeStyles` and `preventForcedColors` styling utils
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated `EuiRangeTooltip` to be easier to see in dark mode
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated some deprecated color token usages that have direct
substitutes ([#8444](https://github.com/elastic/eui/pull/8444))
- `text` -> `textParagraph`
- `title` -> `textHeading`
- `subduedText` -> `textSubdued`
- `disabledText` -> `textDisabled`
- `accentText` -> `textAccent`
- `dangerText` -> `textDanger`
- `warningText` -> `textWarning`
- `useEuiShadow()` now accepts a second `options` argument
([#8234](https://github.com/elastic/eui/pull/8234))
- `useEuiShadowFlat()` now accepts an `options` object instead of only a
color ([#8234](https://github.com/elastic/eui/pull/8234))
- Updated `EuiPopover` and `EuiToolTip` to be easier to see in dark
mode. ([#8174](https://github.com/elastic/eui/pull/8174))
**Bug fixes**
- Fixed a visual bug where a transparent border would create visible
empty space (`LIGHT` mode only) for the components:
([#8427](https://github.com/elastic/eui/pull/8427))
- `EuiPanel`
- `EuiPopover`
- `EuiToolTip`
- `EuiToast`
- `EuiTour`
---
### `@elastic/eui-theme-common`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Removed type `EuiShadowCustomColor`
([#8444](https://github.com/elastic/eui/pull/8444))
- Added types: ([#8444](https://github.com/elastic/eui/pull/8444))
- `EuiShadowOptions`
- `EuiThemeHighContrastModeProp`
- `EuiThemeHighContrastMode`
- Updated shadow utils to accepts a second `options` argument and return
borders in high contrast mode:
([#8444](https://github.com/elastic/eui/pull/8444))
- `euiShadow`
- `euiShadowXSmall`
- `euiShadowSmall`
- `euiShadowMedium`
- `euiShadowLarge`
- `euiSlightShadowHover`
- `euiShadowFlat`
---
### `@elastic/eui-theme-borealis`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Added new component level tokens:
([#8444](https://github.com/elastic/eui/pull/8444))
- `buttonGroupBackgroundDisabledSelected`
- `overlayMaskBackground`
- `overlayMaskBackgroundHighContrast`
- `skeletonBackgroundSkeletonMiddleHighContrast`
## Additional changes
The latest `@elastic/eui` package introduces high contrast mode support.
This PR sets all usages of `EuiProvider` to use
`highContrastMode={false}` to introduce it in disabled state (this
reflects the current functionality in Kibana). This is because the UI
for the high contrast mode functionality (and style adjustments) need to
first be implemented on Kibana side (by shared-ux).
## QA
Adding high contrast mode in disabled state should result in no visual
changes in Kibana. Please ensure your product view remain unchanged.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Related to https://github.com/elastic/docs-content/pull/914
Removes reliance on temporary redirects in the docs-content repo.
@florent-leborgne can you help me with backport labels? I always get
mixed up across repos.
<img width="486" alt="Screenshot 2025-03-19 at 11 39 47"
src="https://github.com/user-attachments/assets/77f4fda2-89a5-4250-a944-699eb2bf8957"
/>
If streams is enabled and the data stream is not hidden, a promotional
component is shown in the flyout that tells people to go there.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
While documenting some Lens architecture I've noticed how chunks are
organized in Lens, so I've taken a quick spin to reduce the amount of
requests to load a dashboard panel and more in general the number of
async chunks produced by webpack.
This PR aims to do 2 things:
* optimize the number of chunks generated by webpack
* optimize the number of requests done to load a Lens embedable panel
* optimize any `await` flow to do **other things ™️ ** while in idle to
load
### Final results
#### Reduce the number of chunks
The final number of chunks got reduced from 24 to 15. The bundle size
has remained almost the same.
| Before | After |
| ------------- | ------------- |
| <img width="1443" alt="Screenshot 2025-03-10 at 12 53 21"
src="https://github.com/user-attachments/assets/65030955-7b7c-493c-9559-fbb9ef9089d4"
/> | <img width="1101" alt="Screenshot 2025-03-10 at 12 51 53"
src="https://github.com/user-attachments/assets/99b9b78d-931a-40ed-bda6-820584c1337e"
/> |
There's still some improvement margin here, but the changes mainly
includes he followings:
* the embeddable is now bundled together with the `async_services`
bundle
* as both are required to render the panel in a dashboard, this change
should speed up a bit the dashboard use case vs the Lens editor one
* Expression implementations has been deferred into their separate
bundles
* this should reduce a bit the initial `plugin.js` bundle by few kb
* most of the times the bundled expressions are used together, so it
makes sense to bundle those 3/4 together rather than have 4 tiny bundles
to async load and prevent waterfall `async import` calls which led to
poor performance
* Defer a component in the `@kbn/unified-field-list` component
* this was making load some edit component within the `async_services`
bundle even in dashboard.
* because this is a component only required in Lens editor, this has
been deferred
* Async register actions as recommended by @nreese
#### Reduce the number of requests
The final number of chunks requested to load a lens panel on a dashboard
went from 12 to 4.
The overall bundle size has remained almost the same, but the
distributions of weights have slightly changed.
Surprisingly there's 1 MB which is gone somewhere, but that doesn't seem
to have an actual impact on the overall loading experience yet.
| Before | After |
| ------------- | ------------- |
| <img width="1445" alt="Screenshot 2025-03-10 at 12 58 08"
src="https://github.com/user-attachments/assets/faab091b-305d-43ad-8be2-2f3bb83913a3"
/> | <img width="1110" alt="Screenshot 2025-03-10 at 12 58 32"
src="https://github.com/user-attachments/assets/f88ac9f5-80a6-42d3-8e3b-3013df05cb8b"
/> |
#### Optimize any `await` call
Well, this is hard to test. So I have no direct proof at the moment. 🤷
cc @thomasneirynck
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR fixes a bug where the test would run at midnight and due to the
odd timing, the index which gets created is asserted for a different
date than expected.
With this fix, we don't check the complete index name now by replacing
the date assertion part with startWith and endsWith assertions.
## Summary
Another small refactor follow up to
https://github.com/elastic/kibana/pull/212694. Overall, the goal here is
to increase consistency in how security rule executors receive common
parameters. `CreateRuleOptions` contained parameters that were passed in
to every security rule type and sometimes used in the `executor` -
bypassing the executor function's parameters. With this PR, params that
are used across multiple security rule type executors like `licensing`,
`experimentalFeatures`, `scheduleNotificationResponseActionsService`,
etc are all passed through the executor options from the shared security
rule type wrapper.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Enabled @typescript-eslint/consistent-type-imports eslint rule for
ResponseOps packages and plugins:
- this rule ensures that imports used only for type declarations are
consistently written using import type syntax
- fixed type imports in:
- x-pack/platform/plugins/shared/event_log
- x-pack/platform/plugins/shared/rule_registry
- x-pack/platform/plugins/shared/task_manager
- x-pack/solutions/observability/packages/kbn-alerts-grouping
- src/platform/packages/shared/kbn-alerts-ui-shared
- src/platform/packages/shared/kbn-alerting-types
- src/platform/packages/shared/kbn-cases-components
- src/platform/packages/shared/kbn-actions-types
- src/platform/packages/shared/kbn-alerts-as-data-utils
- src/platform/packages/shared/kbn-grouping
- src/platform/packages/shared/kbn-rrule
- src/platform/packages/shared/kbn-rule-data-utils
- src/platform/packages/shared/kbn-triggers-actions-ui-types
- x-pack/platform/packages/shared/kbn-alerting-comparators
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Attempts to fix the flakyness of #203179 by waiting for the mocked
request to complete instead of the text finder to timeout. Timing
analysis shows a reduction from `~4000ms` down to just `~70ms` of wait
time for the final assertion.
## References
Closes#203179
Fixes https://github.com/elastic/kibana/issues/212851
## Summary
This PR fixes the autocomplete insert text, which was incorrectly always
adding a template due to the changes made in
https://github.com/elastic/kibana/pull/210187. This PR reverts most of
these changes and instead fixes
https://github.com/elastic/kibana/issues/208862 by fixing the value of
`context.addTemplate`. It also adds unit tests for the `getInsertText`
function.
Requests to test:
**Test 1:**
```
GET index/_search
{"query": {te}}
```
should autocomplete to
```GET index/_search
{
"query": {
"term": {
"FIELD": {
"value": "VALUE"
}
}
}
}
```
Same for the request below:
```
GET index/_search
{
"query": {
te
}
```
**Test 2:**
In the following request, deleting `AGG_TYPE` and replacing it with
`terms` is correctly autocompleted:
```
GET /_search
{
"aggs": {
"NAME": {
"AGG_TYPE": {}
}
}
}
```
autocomplete to:
```
GET /_search
{
"aggs": {
"NAME": {
"terms": {}
}
}
}
```
**Test 3:**
Insert the following request
```
GET /_search
{
"query": {
"match_all": {}
}
}
```
Put the cursor at the end of the `match_all` field (right before the
closing quote) and then delete a few of the last characters. Retype one
character in order to get the suggestions popup displayed. Then press
Enter to add a suggestion.
Verify that the suggestion is added with no extra quote in the
beginning.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/202328
The test itself wasn't failing but the setup was. The test failing does
so because it's the first one in the test suite. We are trying to click
on the flyout save button twice one right after the other. What I think
is happening is that the first one manages to close the flyout before
the second click gets the chance to trigger.
Also the image in CI is this where we can see the flyout is closed
already but it's still trying to close it
## Summary
This PR is a part of SCSS migration of SharedUX team code.
Here is a [meta](https://github.com/elastic/kibana-team/issues/1417)
issue for it.
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
## Summary
The Risk Summary in the Entity Flyout was displaying an incorrect risk
score due to the space name not being accounted for in the risk score
index query.
This update ensures that the namespace is properly considered while
querying the risk score, providing accurate results across different
spaces.
Screen recording :
https://github.com/user-attachments/assets/91df526c-1c22-4d53-aa0c-d74abb54920a
Testing Steps :
1. Navigate to Entity Risk Score page.
2. Add data in the `default` space
3. Check for Risk score in the Risk Summary for any of the entities in
the Entity Flyout.
4. The Risk score in the Entities table and the flyout should be same
5. Create a new space
6. Add data in the new space
7. Check for Risk score in the Risk Summary for any of the entities in
the Entity Flyout.
8. The Risk score in the Entities table and the flyout should be same
### 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [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)
## Summary
This PR adds the SiemSearchBar to the alert summary page. The search bar
is pretty basic: it hides the query menu and the filter buttons to the
left of the query input. Instead, the PR builds a new filter button.
That button lists all the sources available. Sources are basically
equivalent to integrations, or their corresponding rules. It is a
friendly UI name to abstract the concept or a rule.
In the AI for SOC effort, each integration is bundled with a single
rule. This means that deselecting a source from the Source filter button
is equivalent to adding a filter to the search bar to exclude all alerts
with the `kibana.alert.rule.name` property having the value of that
integration.
### Example:
There are following 2 integrations installed:
```typescript
[
{
id: 'splunk',
name: 'splunk',
status: installationStatuses.Installed,
title: 'Splunk',
version: '',
},
{
id: 'google_secops',
name: 'google_secops',
status: installationStatuses.Installed,
title: 'Google SecOps',
version: '',
},
]
```
This means that - in theory - there are the following 2 rules installed
and running:
```typescript
[
{
related_integrations: [{ package: 'splunk' }],
name: 'Splunk Rule',
},
{
related_integrations: [{ package: 'google_secops' }],
name: 'Google SecOps Rule',
},
]
```
In this case, the `Sources` button would show 2 entries, as follow:
```typescript
[
{
checked: 'on',
key: 'Splunk Rule',
label: 'Splunk',
},
{
checked: 'on',
key: 'Google SecOps Rule',
label: 'Splunk',
},
]
```
By default, the `checked` property should be set to `on`. It would be
`off` if a filter for the corresponding `label` existed.
https://github.com/user-attachments/assets/059815d2-9181-4bf1-bd78-e0e5bfa7439dhttps://github.com/user-attachments/assets/126606c7-b4e0-4d0b-82c1-b531c6490de3
## How to test
This needs to be ran in Serverless:
- `yarn es serverless --projectType security`
- `yarn serverless-security --no-base-path`
You also need to enable the AI for SOC tier, by adding the following to
your `serverless.security.dev.yaml` file:
```
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
And this to generate data: `yarn test:generate:serverless-dev`
Use one of these Serverless users:
- `platform_engineer`
- `endpoint_operations_analyst`
- `endpoint_policy_manager`
- `admin`
- `system_indices_superuser`
### Notes
You'll need to either have some AI for SOC integrations installed, or
more easily you can:
- change the `alert_summary.tsx` line `38` from `if
(installedPackages.length === 0) {` to `if (installedPackages.length >
0) {` to force the wrapper component to render
- update `42` of the same `alert_summary.tsx` file from `return <Wrapper
packages={installedPackages} />;` to `return <Wrapper
packages={availablePackages} />;` to be able to see some packages
- comment out line the if condition line `66` of `use_integrations.ts`
file to make sure that values are added even if there is no
`matchingRule`
- replace `const ruleName = changedOption.key;` with `const ruleName =
changedOption.label;` on line `78` of the
`integrations_filter_button.tsx` file
### Checklist
- [x] 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)
- [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
### Links
Ticket https://github.com/elastic/security-team/issues/11956
Mocks
https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-70999&m=dev
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base-fips | digest | `d70e923` ->
`60d2da3` |
---
### 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://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwiY2k6YnVpbGQtZG9ja2VyLWZpcHMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR partially solves issue #214346 by adding the KQL Filter when
creating a TLS Alerting Rule.
Because of [the intermediate release
process](https://docs.google.com/document/d/1mU5jlIfCKyXdDPtEzAz1xTpFXFCWxqdO5ldYRVO_hgM/edit?tab=t.0#heading=h.2b1v1tr0ep8m)
the UI to add the new filters is not shown, another PR will enable it
after the next serverless release.
In details:
BE:
- Extended `tlsRuleParamsSchema` to accept `monitorIds`, `locations`,
`tags`, `monitorTypes`, `projects`, `kqlQuery`
- Extended `TLSRuleExecutor` functionality, added tests
- Added new `/internal/synthetics/inspect_tls_rule` endpoint
FE:
- Added `AlertSearchBar`, `FieldFilters` and `TLSRuleViz` to the
`TLSRuleComponent`, making sure that only `http` and `tcp` monitors are
considered
Final result:
https://github.com/user-attachments/assets/613cdb73-2184-4b10-8dd5-549868b7672d
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
