## Summary
Closes https://github.com/elastic/kibana/issues/184257
This PR removes the modal warning users that unsaved changes would be
lost when navigating away from dashboard to other apps within Kibana.
The modal is not necessary since unsaved changes are saved in session
storage. The benefit is that this removes the unnecessary click for
users.
This does not impact the modal for switching to view mode from edit mode
with unsaved changes as shown below.
https://github.com/user-attachments/assets/c5bdb0ec-b040-40b0-a511-fd16ad084b90
### Checklist
- [x] Update tests
- Closes https://github.com/elastic/kibana/issues/198496
## Summary
This PR fixes an issue when the histogram request returns only a partial
result (0 or greater than 0) by adding a warning icon next to the total
hits counter and not blocking the whole page with "No results" message
(when partial result with 0 hits from histogram).
<img width="1436" alt="Screenshot 2024-10-31 at 15 45 17"
src="https://github.com/user-attachments/assets/9a769fe6-bdcf-4d20-ae6e-698a5b08d76f">
### Testing
Execute the following and open `example*` data view in Discover.
```
PUT example1
PUT example1/_mapping
{
"properties": {
"message": {
"type": "text"
},
"date": {
"type": "date"
}
}
}
PUT example1/_doc/11
{
"message": "11",
"date": "2024-11-11T12:10:30Z"
}
PUT example1/_doc/12
{
"message": "22",
"date": "2024-11-12T12:10:30Z"
}
PUT example2
PUT example2/_mapping
{
"properties": {
"message": {
"type": "keyword"
},
"date": {
"type": "date"
}
}
}
PUT example2/_doc/21
{
"message": "21",
"date": "2024-12-01T12:10:30Z"
}
PUT example2/_doc/22
{
"message": "22",
"date": "2024-12-02T12:10:30Z"
}
```
Then add `message` as a breakdown field.
Notice that the histogram gets some partial results:
<img width="1563" alt="Screenshot 2024-10-31 at 16 11 14"
src="https://github.com/user-attachments/assets/8a53f661-38a2-48f8-b082-823de77ac4f2">
Now, add a filter for `_id: 11` and notice that the histogram request
has no results (it partially failed on some shards) but Discover still
renders the table:
<img width="1564" alt="Screenshot 2024-10-31 at 16 11 31"
src="https://github.com/user-attachments/assets/e154ab5d-c5d4-4703-abd4-7bf3cd7a15fb">
### 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/packages/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
---------
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
## Summary
Closes https://github.com/elastic/kibana/issues/184631
It keeps the chart configuration when the user is doing actions
compatible with the current query such as:
- Adding a where filter (by clicking the table, the sidebar, the chart)
- Changes the breakdown field and the field type is compatible with the
current chart
- Changing to a compatible chart type (from example from bar to line or
pie to treemap)
- Changing the query that doesnt affect the generated columns mapped to
a chart. For example adding a limit or creating a runtime field etc.
The logic depends on the suggestions. If the suggestions return the
preferred chart type, then we are going to use this. So it really
depends on the api and the type / number of columns. It is as smarter as
it can in order to not create bugs. I am quite happy with the result. It
is much better than what we have so far.
### Next steps
I would love to do the same on the dahsboard too, needs more time
though. But the changes made here will def work in favor
### 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] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
## Summary
Hello, this PR addresses the deprecation of square brackets in FROM
METADATA declarations in Elasticsearch queries, in preparation for
Elasticsearch 9.0. Closes#196988
The changes involve removing square brackets around metadata fields
(e.g., `[metadata _id]` becomes `metadata _id`) across various parts of
the codebase. No functional changes to the UE, only internal query
syntax updates.
### 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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
- [ ] This will appear in the **Release Notes** and follow the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Fixes https://github.com/elastic/kibana/issues/197342
In this PR (https://github.com/elastic/kibana/pull/197101) I removed the
legacy metric from being suggested in the suggestion panel, and replaced
it with the new metric visualization. To maintain the previous behavior
in Lens (suggesting a new metric in the same place as legacy metric), we
made the score higher for the new metric. This positioned it higher also
in the Discover ESQL suggestions. This led to an issue where one
expected suggestion didn’t appear because we only display the top 6
suggestions by score and it got pushed out by metric.
Additionally, I made a change here to only display the metric without
bucketed columns in the suggestion panel. I don't see there's a lot of
value in suggesting bucketed metric unless it's something user chooses
intentionally.
Should be merged to 8.x after this:
https://github.com/elastic/kibana/pull/197337
## Summary
This adds the AI assistant to Serverless Elasticsearch. It also disables
the knowledge base, and disables a few config values we don't want users
to be able to set in that context.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elena Shostak <165678770+elena-shostak@users.noreply.github.com>
## Summary
This PR makes sure to pass `filters` to DocViewer from the search panel
on Dashboard. And DocViewer will pass `filters` over to Surrounding Docs
page.
### 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
Adds a new API deprecations feature inside core.
This feature enabled plugin developers to mark their versioned and
unversioned public routes as deprecated.
These deprecations will be surfaced to the users through UA to help them
understand the deprecation and address it before upgrading. This PR also
surfaces these deprecations to UA.
Closes https://github.com/elastic/kibana/issues/117241
1. Core service to flag deprecated routes
2. UA code to surface and resolve deprecated routes
## Flagging a deprecated Route
### The route deprecation option
We have three types of route deprecations:
- `type: bump`: A version bump deprecation means the API has a new
version and the current version will be removed in the future in favor
of the newer version.
- `type: remove`: This API will be completely removed. You will no
longer be able to use it in the future.
- `type: migrate`: This API will be migrated to a different API and will
be removed in the future in favor of the other API.
All route deprecations expect a documentation link to help users
navigate. We might add a generic documentation link and drop this
requirement in the future but for now this is required.
### Deprecated Route Example
Full examples can be found in the `routing_example` example plugin
located in this directory:
`examples/routing_example/server/routes/deprecated_routes`
```ts
router[versioned?].get(
{
path: '/',
options: {
deprecated: {
documentationUrl: 'https://google.com',
severity: 'warning',
reason: {
type: 'bump',
newApiVersion: '2024-10-13',
},
},
},
},
async (context, req, res) => {
...
```
## Surfaced API deprecations in UA
The list of deprecated APIs will be listed inside Kibana deprecations
along with the already supported config deprecations.
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/5bece704-b80b-4397-8ba2-6235f8995e4a">
Users can click on the list item to learn more about each deprecation
and mark it as resolved
<img width="1476" alt="image"
src="https://github.com/user-attachments/assets/91c9207b-b246-482d-a5e4-21d0c61582a8">
### Marking as resolved
Users can click on mark as resolved button in the UA to hide the
deprecation from the Kiban deprecations list.
We keep track on when this button was clicked and how many times the API
has been called. If the API is called again the deprecation will
re-appear inside the list. We might add a feature in the future to
permenantly supress the API deprecation from showing in the list through
a configuration (https://github.com/elastic/kibana/issues/196089)
If the API has been marked as resolved before we show this in the flyout
message:
> The API GET /api/deprecations/ has been called 25 times. The last time
the API was called was on Monday, October 14, 2024 1:08 PM +03:00.
> The api has been called 2 times since the last time it was marked as
resolved on Monday, October 14, 2024 1:08 PM +03:00
Once marked as resolved the flyout exists and we show this to the user
until they refresh the page
<img width="1453" alt="image"
src="https://github.com/user-attachments/assets/8bb5bc8b-d1a3-478f-9489-23cfa7db6350">
## Telemetry:
We keep track of 2 new things for telemetry purposes:
1. The number of times the deprecated API has been called
2. The number of times the deprecated API has been resolved (how many
times the mark as resolved button in UA was clicked)
## Code review
- [x] Core team is expected to review the whole PR
- [ ] Docs team to review the copy and update the UA displayed texts
(title, description, and manual steps)
- [x] kibana-management team is expected to review the UA code changes
and UI
- [ ] A few teams are only required to approve this PR and update their
`deprecated: true` route param to the new deprecationInfo object we now
expect. There is an issue tracker to address those in separate PRs later
on: https://github.com/elastic/kibana/issues/196095
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the console to trigger the deprecation condition so they
show up in the UA:
```
# Versioned routes: Version 1 is deprecated
GET kbn:/api/routing_example/d/versioned?apiVersion=1
GET kbn:/api/routing_example/d/versioned?apiVersion=2
# Non-versioned routes
GET kbn:/api/routing_example/d/removed_route
POST kbn:/api/routing_example/d/migrated_route
{}
```
1. You can also mark as deprecated in the UA to remove the deprecation
from the list.
2. Check the telemetry response to see the reported data about the
deprecated route.
3. Calling version 2 of the API does not do anything since it is not
deprecated unlike version `1` (`GET
kbn:/api/routing_example/d/versioned?apiVersion=2`)
4. Internally you can see the deprecations counters from the dev console
by running the following:
```
GET .kibana_usage_counters/_search
{
"query": {
"bool": {
"should": [
{"match": { "usage-counter.counterType": "deprecated_api_call:total"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:resolved"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:marked_as_resolved"}}
]
}
}
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fix loading state management in `use_discover_histogram.ts`
Moving the loading state for `totalHits$` to the `fetchAll` function, which is executed before the hook. This ensures that the loading state is set at a higher level, preventing a situation where the overall data fetching is in a `loading` state, but the histogram is marked as `complete` while receiving new properties (like a new data view ID) without access to refreshed data views.
## Summary
We're working on upgrading Kibana to React@18 (in Legacy Mode). There
are a couple failing tests when running React@18 in Legacy mode and this
is one of them
[[job]](https://buildkite.com/elastic/kibana-pull-request/builds/243743#01929ee7-11b8-41c3-af79-1437561a6ef0)
[[logs]](01929f0a-dc7a-42ff-9a01-809c31e1dc71)
FTR Configs #58 / discover/group3 discover doc viewer flyout
accessibility should use expected a11y attributes
This one is simple. Native to react `useId` implementation produces ids
like this: `:r3:` and when you attempt to use such ids with id selector
they're invalid . e.g. `document.querySelector('#:r3:')` throws an
error. A workaround is to use attribute selector
`document.querySelector('[id=":r3:"]')`. This is the same problem as
we've seen before https://github.com/elastic/kibana/pull/191632
Fixes https://github.com/elastic/kibana/issues/190818
## Summary
Elasticsearch has added support for GeoIP, enabling the use of paid
GeoIP databases from MaxMind/IPInfo for more accurate and granular
geolocation data. As such we should add support to ingest pipelines UI
for making this available to the user.
* If the user doesn't have enough privileges, the "Manage Pipelines"
link and UI won't show.
* Users can add two types of databases through the UI: MaxMind and
IPinfo. Database names are predefined by ES, and the user cannot enter
their own.
* Certain types of databases (local and web) can be configured through
ES, and these will appear in the UI, but they cannot be deleted as they
are read-only.
* When configuring a `IP location` processor, the database field will
display a list of available and configured databases that the user can
select. It also allows for free-text input if the user wants to
configure a database that does not yet exist.
* The new IP location processor is essentially a clone of the GeoIP
processor, which we are moving away from due to copyright issues.
However, it was decided that GeoIP will remain as is for backward
compatibility, and all new work will only be added to IP location going
forward.
* I left a few mocks in the `server/routes/api/geoip_database/list.ts `
to try `local/web` types
## Release note
The Ingest Pipelines app now supports adding and managing databases for
the GeoIP processor. Additionally, the pipeline creation flow now
includes support for the IP Location processor.
<details>
<summary>Screenshots</summary>
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Ignacio Rivas <rivasign@gmail.com>
Co-authored-by: Elena Stoeva <elenastoeva99@gmail.com>
Co-authored-by: Elena Stoeva <59341489+ElenaStoeva@users.noreply.github.com>
Co-authored-by: Matthew Kime <matt@mattki.me>
## Summary
#### Different vCPUs ranges and enabling support for static allocations
based on the serverless project type
- Each serverless config yml, e.g.
[search.es.yml](84b3b79a15/config/serverless.es.yml (L61))
now contains parameters required for start model deployment:
```yml
xpack.ml.nlp:
enabled: true
modelDeployment:
allowStaticAllocations: true
vCPURange:
low:
min: 0
max: 2
static: 2
medium:
min: 1
max: 32
static: 32
high:
min: 1
max: 512
static: 512
```
Note: _There will be no static allocations option for serverless O11y
and serverless Security._
#### The minimum values of vCPUs
- 0 for the Low usage level on both serverless and ESS.
- 1 for the Medium and High usage levels on both serverless and ESS.
#### The default vCPUs usage levels
- Low in serverless.
- Medium in ESS and on-prem
### 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 actually uses the Search Assistant scope to modify the assistant's
behavior depending on the context they're in. The assistant now:
- Defaults to Observability mode
- Is a Search assistant in the Search pages
- Switches dynamically, changing available functions, prompts and
instructions based on context
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Make the following changes to the integrations page:
- Rename `enterprise_search` category to `search`
- Remove `Application Search` tag
- Remove the JSON tile entirely
## Summary
This extracts the Observability AI Assistant into a shared package so
Search and Observability can both consume it.
A few notes:
This still relies on significantly tight coupling with the Obs AI
assistant plugin, which we will want to slowly decouple over time. It
means that currently to consume this in multiple places, you need to
provide a number of plugins for useKibana. Hopefully we can get rid of
that and replace them with props eventually and make the interface a
little less plugin-dependent.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adding `functional_search` suite with a set of test for the search
solution navigation. But this suite will also grow to test search
solution pages that do not require the enterprise search node.
### 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] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
## 📓 Summary
Closes#193319Closes#193320
This work is part of the effort to progressively deprecate the existing
Logs Stream feature.
Changes taken on this PR consist of:
- Create a new uiSettings `observability:enableLogsStream` which
defaults to `false` on the stateful/cloud deployments and is not
available in serverless ones (still, defaults to `false` behind the
scene).
- When `observability:enableLogsStream` is `false`, the Logs Stream page
route is not registered, and neither is its deep link for global search.
- When `observability:enableLogsStream` is `false`, the panels list on
Dashboard won't show anymore the option `Logs Stream (Deprecated)` to
prevent usage of this embeddable in new dashboards. The embeddable is
still registered for retro-compatibility with active dashboards, and it
has now a callout explaining the status of this embeddable
(unmaintained/deprecated).
- Rename logs ML to "Logs Anomalies" and "Logs Categories".
Other minor improvements regard:
- Remove duplicate Xstate utils and use the relative package instead.
- Remove the duplicated `useBoolean` hook used in the deprecation
callout.
- Sync deep links registration with available routes through a single
`getLogsRoutes` util.
## 🎥 Recordings
### Logs Stream app removed
https://github.com/user-attachments/assets/f4173294-8789-4abd-9972-29c9b7c197ed
### Logs Stream dashboard panel entry removed
https://github.com/user-attachments/assets/7f99ca2a-c030-4867-b976-8fdc1df09d29
### Logs Stream app removed from project nav
https://github.com/user-attachments/assets/de51bdd6-820a-4c03-8b64-fb1a6ced0a12
### Embeddable deprecation callout
<img width="949" alt="Screenshot 2024-10-02 at 10 22 09"
src="https://github.com/user-attachments/assets/99fd5554-004b-45e4-81db-cb23947e210e">
### Unavailable setting in serverless
https://github.com/user-attachments/assets/91bf6c37-0845-4918-a485-b6250bbd96bf
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mike Birnstiehl <114418652+mdbirnstiehl@users.noreply.github.com>
