Currently Kibana forwards `query_range_secs` and `query_offset_secs` to
mark the selected time range when reporting TTFMP event. This format
caused some challenges to identify `from`, `to` date offsets in
visualizations.
To simplify, the PR renames and sends the three fields explicitly:
- `query_from_offset_secs` offset to `0` (now), with -ve for past and
+ve for future dates
- `query_to_offset_secs` offset to `0` (now), with -ve for past and +ve
for future dates
- `query_range_secs` same as previously sent
_This approach is followed after a discussion, and based on the
[gist](https://gist.github.com/andrewvc/1f04a57a336d768e4ec5ff2eff06ba54)
excerpt:_
```
Earliest date -> QueryFrom
Newest date -> QueryTo
Duration -> QueryRange
```
### Indexing
These fields then should be mapped in the EBT indexer to ingest in the
top level of the document, eventually removing the need to create
runtime fields in data views for visualizations.
Also, runtime fields in data views should be updated to reflect this
change. For backward compatibility, the runtime fields can cater both
the old and new field names conditionally.
### Testing
- Ensure that the TTFMP events are correctly reporting the date ranges.
### Example
## Summary
The intent is to have a centralised place to store the list of Kibana
solutions and serverless project types.
To that end, this PR creates a `@kbn/projects-solutions-groups` package.
It also adds the new solution type `'chat'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
The code changes in this PR ensure that the transform ID is limited to
36 characters when creating or updating the transform for risk-score.
This adjustment aligns with ES constraint on transform ID length.
## Test Steps
1. Create a new namespace with a very long name. Ex :
`namespace_that_stretches_farther_than_the_universe_and_beyond_like_buzz`
🚀
2. Enable the Risk Score in the new namespace. It should successfully
get enabled.
3. Check the transform that was created (using dev tools)
```
GET _transform/risk_score_latest_transform_*?filter_path=transforms.id,transforms._meta.space_id
```
Output
### 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] 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)
- [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)
---------
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
# Purpose
This change introduces new validations that ensure no loss of data is
possible if a user accidentally sets the Security Entity Store enrich
policy execution interval to a value that “doesn’t play nicely” with the
lookback period value.
The specific logic (greater than or equal to half the value) was chosen
to not only ensure no loss of data, but also provide extra resiliency in
case of a failed enrich policy execution.
(Note that this is not considered a breaking change, as the parameters
are not yet available on any version of Elastic, including Serverless.)
# How to test
1. Load appropriate entity log data to your Kibana instance (for
example, using the
[security-documents-generator](https://github.com/elastic/security-documents-generator))
2. Navigate to the Developer console
3. Attempt to enable the Entity Store via the /enable or /init routes
(examples below), and pass in values that are expected to error. For
example, “lookbackPeriod”: “24h” and “enrichPolicyExecutionInterval”:
“24h” should fail, because of the validation logic
4. Expect results similar to those shown below, specifically a 400
error, or else a success message
<img width="1902" alt="Screenshot 2025-02-27 at 12 57 45 AM"
src="https://github.com/user-attachments/assets/a7f4b0fb-9899-4e00-a0ae-d172245bd506"
/>
<img width="1909" alt="Screenshot 2025-02-27 at 12 58 06 AM"
src="https://github.com/user-attachments/assets/372acde2-9d7b-4c75-8596-af8374088f79"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
https://github.com/elastic/kibana/issues/209258 updates the settings
endpoint to also be able to get/set the alert deletion settings. The
alert deletion setting should make use of this new endpoint to load its
initial data and store any user update.
> [!WARNING]
> This will be merged into a feature branch.
## QA:
Activate the feature flag
```
# config/kibana.dev.yml
xpack.trigger_actions_ui.enableExperimental: ['alertDeletionSettingsEnabled']
```
Follow these steps:
- Go to rules
- Click on settings
- Change the alert deletion settings
- Click on save
- Reload and check the settings kept the values
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This updates the versioning tags in the Alert and Action settings yaml
file to use `all` instead of `ga`. I guess the former makes more sense
since these settings aren't newly GAed.
The PR also makes a couple of very minor content changes based on
https://github.com/elastic/kibana/pull/214934
fixes [214636](https://github.com/elastic/kibana/issues/214636)
## Summary
Fix the random id generator, it would sometimes generate an id longer
than the specified length.
> Error: generated id is longer than 16 characters: 17
Closes https://github.com/elastic/kibana/issues/190381
## Summary
This PR adds the ability to drag and drop rows by their headers in order
to reorder them:
It can be a bit confusing dragging section headers around when other
sections are expanded - it is easy to lose track of them, especially
when the expanded sections are very large. I experimented with
auto-collapsing all sections on drag, but this felt extremely
disorienting because you instantly lost all of your context - so, to
improve the UI here, I added a "scroll to" effect on drop like so:
https://github.com/user-attachments/assets/0b519783-a4f5-4590-9a1c-580df66a2f66
Reminder that, to test this feature, you need to run Kibana with
examples via `yarn start --run-examples` and navigate to the grid
examples app via `Analytics > Developer examples > Grid Example`.
### 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)
### Identify risks
Collapsible sections are not available on Dashboard yet and so there is
no user-facing risk to this PR.
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `5ba5def` ->
`c4e10ec` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
This pr fixes some odd issues with getBulkActions, which is really a
hook in disguise, as well as an issue with the useGetMutedAlertsQuery
hook, which was/is fetching data much more often than it should, exactly
why that is I'm not sure, perhaps something to do with how timeline
blocks focus to the underlying DOM when it's open, and this causes the
default to true refetchOnWindowFocus prop of useQuery to re-run the
query, or if there's an error with the queryKey.
Below are 2 GIFs comparing react performance profiles of simply opening
and then closing the timeline while on the alerts page with 50 alerts in
the table.
Before fix:
12 renders for a total of 950 ms, a large portion of which is coming
from the alert table cells.
After fix:
8 renders for a total of 380 ms, almost none of it coming from the alert
table.
Each of the alerts table and timeline/discover drive some of the more
stateful and complex workflows in kibana on their own, and on top of
that one is rendering within a flyout on top of the other, listening to
the same url changes/tens of context provider wrappers changing above
them in the tree/kibana services, etc, & so proper memoization is a
pre-requisite for a good ux.
### 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
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
Co-authored-by: Ashokaditya <ashokaditya@elastic.co>
Co-authored-by: Viduni Wickramarachchi <viduni.wickramarachchi@elastic.co>
## Summary
Addresses https://github.com/elastic/kibana/issues/209048
1. Started ES with
```
yarn es snapshot --version 8.19.0 --data-archive=../kibana/x-pack/test/upgrade_assistant_integration/fixtures/data_archives/upgrade_assistant.zip
```
2. Then created updated archive
```
zip -r ../../../kibana/x-pack/test/upgrade_assistant_integration/fixtures/data_archives/upgrade_assistant.zip data -x "*/\.*"
```
## Summary
Part of https://github.com/elastic/kibana/issues/208908
Replaces scss to css-in-js.
> [!NOTE]
> The rest of the `.scss` will be migrated in different pull requests
<!--
- [ ] `x-pack/platform/plugins/private/graph/`public/_mixins.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_app.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_graph.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_inspect.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_search_bar.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/_search_bar.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/field_manager/_field_picker.scss
- [ ]
`x-pack/platform/plugins/private/graph/`public/components/field_manager/_index.scss
-->
### Checklist
- [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
### Fleet
- Exposed API route for bulk get package policies via the routes service
- Created and exposed type `BulkGetPackagePoliciesRequestBody`
<br/>
### Security Solution
The following changes were made to Endpoint Artifacts in support of
spaces:
> [!NOTE]
> Space awareness is currently behind feature flag:
`endpointManagementSpaceAwarenessEnabled`
- The policy assignment component, which is displayed on artifact's
Create and Update forms, now:
- Displays the count of policies (if any) that are associated with the
artifact, but not currently accessible in the active space (screen
capture 1️⃣ )
- When a user does NOT have the Global Artifact privilege, the `Global`
toggle selection will be disabled and a tooltip is displayed. This
change also applies to the create form where the default selection will
be per-policy and the global button will be disabled. (screen capture
2️⃣ )
- Artifact policy assignments that are not accessible in active space
are preserved when submitting an update to the artifact
- The component was also refactored a bit to simplify its list of props
- Artifact card policy assignment menu was adjusted to show any policy
that is not accessible to the user as "disabled" along with a tooltip
(screen capture 3️⃣ )
- The update artifact API was changed (via server-side extension point)
to not error when validating policies that are not accessible in active
space if they were already associated with the item being updated.
- Fixes a bug in the Find artifacts API (impact only when spaces was
enabled) where an invalid filter was created when there was no policies
currently shared with active space.
## Summary
Addresses https://github.com/elastic/kibana/issues/167273
* Breaks down the `beforeAll` logic in 3 different hooks (allowing for
bigger margin for each).
* Updates the logic that fills the `existing_index_with_100k_docs`
index, using `refresh: 'wait_for'` only in the last iteration.
* Fixes a source of flakiness: a search request that was returning
results in random order.
The most recent failure was:
<img width="1140" alt="image"
src="https://github.com/user-attachments/assets/fef18850-ab06-43b0-afd9-671604a5f84a"
/>
## Summary
While doing a POC trying to implement the grouping component with the
UnifiedDataTable, I discovered a rendering issue that caused some sort
of infinite loop rerendering after selecting a group.
This PR fixes that issue but making sure we do not have a new instance
of an empty array every time the component is rendered.
## Summary
This PR reworks how APM handles getting its sources data, elevating the
necessary code to a private shared plugin so that Discover for Traces
can access the data and handle user provided configuration. It also
removes the need for Discover for Traces to rely on the APM static data
view, so the Trace data source and document profile will work on any
compatible/configured index, even in ESQL mode.
Closes#211414
<img alt="ESQL Discover Traces Screenshot 2025-03-04 173032"
src="https://github.com/user-attachments/assets/f5bbb736-8b8b-45dc-ac23-4bf7083aa47e"
/>
## How to test
Test with olbt-cli instance for now, will post for doing with synthtrace
data. Ensure the following is added to your kibana.dev.yml:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
```
- Make sure your space has the Observability solution view configured
- Go to Discover page
- Select Data Views mode if required and create a view with a `traces`
specific index. Or use the APM static data view.
- The default columns on the page should show the summary column with
four of the following badges: `service.name`, `event.outcome`,
`transaction.name`, `transaction.duration.us`, `span.name`,
`span.duration.us`
- Go to ESQL mode with the query targetting a `traces` index
- The default columns should show the same as in Data View mode
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Irene Blanco <irene.blanco@elastic.co>
## Summary
This PR fixes a regression introduced for user messages.
The `viewMode` check moved from observable to its raw value but still
performing the observable check.
The fix is to check both the panel `viewMode` AND as fallback the
embeddable hierarchy viewMode until the `edit` mode is met.
---------
Co-authored-by: Nick Partridge <nick.ryan.partridge@gmail.com>
## Summary
The PR updates the code to extend the lookback period for Risk scoring
calculations from `now-30m` to `now-30d`.
This change impacts:
- Risk score UI (date picker)
- The preview API
- The enable API (for Risk Score Saved Object configuration)
### 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)
Screenshots :
## UI and Preview API payload
## Risk Engine configuration SO
## Testing Steps:
1. Navigate to the Entity Analytics management page (Entity Risk Score
webpage).
2. Ensure the default text in the date picker displays **"Last 30
days"**.
3. Open the **Network** tab in Developer Tools and verify that the
**"preview"** API request reflects a 30-day difference between the
`from` and `to` values.
4. If the **Risk Engine** is enabled, disable it and open a window
displaying Kibana logs.
5. Re-enable the **Risk Engine** and check the logs for the
configuration message: **"Risk engine running with configuration"**. The
expected range should be:
```json
"range": {
"start": "now/M",
"end": "now"
}
```
## Advanced Testing Steps
1. The date picker should default to **"Last 30 days"**. If you change
it to **"Yesterday"** without clicking **Save changes**, the **Preview
API** should reflect "Yesterday," but the **Saved Object (SO)** should
**not** update its range.
2. Upon refreshing the page without saving the changes, the date picker
should reset to its default value, **"Last 30 days"**.
## Summary
Resolves https://github.com/elastic/kibana/issues/210617
Added strip unkowns to nested objects in map, array and record. Added a
lot of test cases to cover things like objects inside maps, objects
inside records, objects inside maps inside records, ...
One thing to note is that we can't apply `stripUnkowns` to
`schema.oneOf` since it's using `joi.alternatives` and you can't use it
there.
### 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] 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)
