To @elastic/kibana-esql and @elastic/appex-sharedux reviewers - the only
change in your code is moving to a `fastest-levenshtein` npm module -
it's way more performant than `js-levenshtein` so I replaced it
everywhere in the codebase (see screenshots at the bottom of this
description).
### Summary
This PR implements fuzzy search for field pickers and field lists across
Kibana.
Fixes https://github.com/elastic/kibana/issues/179898
### Details
* We allow one typo (addition, omission, or substitution of a character)
in the search phrase. Allowing more than one typo results in too many
nonsensical suggestions.
* The feature does not activate for search phrases shorter than 4
characters to avoid nonsensical results (2 or 3 characters and one of
them is typo doesn't sounds correct). If we were to turn it on for
phrases with 3 characters, for example for `geo` search string we'll
activate "messa**ge**", "a**ge**nt" etc (see screenshot) The decision is
up to us, but to me it feels unneccessary.
<img width="532" alt="Screenshot 2024-06-26 at 11 23 17"
src="5ee04e55-fed6-4e4b-9bac-71bcc14b92d0">
* Wildcards and fuzzy search do not work together to avoid performance
problems and potential complex implementation. For example for searching
a field named `content.twitter.image`:
* `contnt.twitter` (typo) matches the field by fuzzy search.
* `content:*image` matches the field by wildcard.
* `content mage` matches the field by space wildcard.
* `contnt:*image` will not work, as combining wildcards with fuzzy
search can significantly impact performance.
#### Peformance improvements (tested on metricbeat data and ~6000
fields)
Unfortunately, adding fuzzy search affects the performance. Before
typing a character in a list so big (6000 fields) would be around 80ms
on my Macbook on dev environment, after adding a fuzzy search it was
around 120ms so I introduced some more performance improvements:
* the fuzzy search compares strings of similar lengths to the search
phrase (±1 character in length) only (not building the whole matrix).
* I also turned off the `i` flag for regex checking wildcards and used
`toLowerCase` instead. That speeds up things a little (10% improvement
checking 50 iterations)
* I also replaced the js-levenshtein npm module with fastest-levenshtein
- that gives around 20-30% speed improvement and with other
optimizations, we cannot see the difference between 'before' and
'after'. (for comparison, see after without moving to
fastest-levenshtein)
I ran the performance profiling many times and the results were stable,
not differing a lot.
**TEST: Typing the string activemp**
before:
<img width="463" alt="Screenshot 2024-06-28 at 11 17 42"
src="42b96783-6d11-4d25-8f21-ef30d8b50167">
after:
<img width="546" alt="Screenshot 2024-06-28 at 11 42 10"
src="33c7c81b-34cc-4e01-9826-7c88d224f938">
after without moving to fastest-levenshtein:
<img width="506" alt="Screenshot 2024-06-28 at 12 55 15"
src="c5b08e7d-aa3b-4430-986f-975bfe46dec6">
### Example
<img width="887" alt="Screenshot 2024-06-25 at 16 14 10"
src="4ba0a892-c22e-4dfc-80c2-18b7b3f2e260">
## Summary
Fixes#187007
Hides ML embeddables from the "Add panel" flyout when
1. ML feature isn't available for the user role
2. ML is hidden in a current space
### How to test
1. Create a custom role with disabled ML privilege and assign it to a
user
2. Remove ML feature visibility in a current space
### 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
As discussed, I looked into making it clearer how to handle the log
stream embeddable panel on dashboards.
It's not possible to show an info icon or a badge without bigger
changes, but there is already a tooltip which can be used for the same
purpose:
<img width="321" alt="Screenshot 2024-07-04 at 11 30 27"
src="60de35b5-559f-4670-b2b9-e074a3cb73c8">
<img width="422" alt="Screenshot 2024-07-04 at 11 31 31"
src="3ba2f87c-dc33-4a6b-bf81-2e561e6b7cec">
I added the "deprecated" to the title instead.
There is code to show a "deprecated" badge, but it only works for
visualization types, not for actions (which is how log stream is
integrated here). Actions currently don't have a notion of deprecation.
It would be possible to add that, but it doesn't seem worth it to
slightly change how the "deprecated" text is rendered.
## Summary
Disables the `@timestamp` sorting for ES|QL Document view.
The sorting doesnt work currently. I could enable it but this causes 2
problems:
- The fix is here
https://github.com/elastic/kibana/blob/main/packages/kbn-unified-data-table/src/components/data_table.tsx#L962
The timestamp column is a special column for Discover so the
columns.length is 0 here even if the timestamp column is being rendered.
As a result the inMemory is false and the client side sorting doesnt
work. Removing the columns.length fixes it but it makes Discover
significantly slower.
- As the data are not by default sorted by timestamp even if we enable
it client side, it won't be of great help. I think that for the
timestamp column it would be better to enable server side sorting but
this needs discussion
I think that hiding this for now it will fix the confusion and is a good
temporary decision before we decide what to do with sorting in general.
## 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>
## Summary
Closes https://github.com/elastic/kibana/issues/144418
This PR introduces changes to the dashboard add panel selection
functionality, so that panel selection would now happen from within a
flyout, and as such panels are now grouped together logically.
With this implementation any panel that is intended to show up within
this new flyout is required to have either been registered leveraging
the ui action trigger `ADD_PANEL_TRIGGER` and have it's `grouping` value
defined or belong to a subset of visualization types (`PROMOTED`,
`TOOLS`, and `LEGACY`) that would automatically get grouped.
It's worth pointing out that because we can't control the order at which
UI actions gets registered, we won't always get the the panel groups in
the same order, for this specific reason ~a new optional property
(`placementPriority`) has been added in~ the property `order` is now
leveraged such that it allows a user registering a UI action define a
relative weight for where they'd like their group to show up. All
registered actions would be rendered in descending order considering all
`order` defined, in the case where no order is defined `0` is assumed
for the group. In addition an action which is registered without a
group, would automatically get assigned into a default group titled
"Other".
The search implemented within the add panel is rudimentary, checking if
the group titles and group item titles contain the input character; when
a group title is matched the entire group is remains highlighted, in the
case that the group isn't matched and it's just the group item, only
said item is highlighted within it's group.
## Visuals
#### Default view
<img width="2560" alt="Screenshot 2024-06-10 at 17 44 17"
src="90aadf82-684a-4263-aecd-2843c3eff3c1">
#### Search match view
<img width="2560" alt="Screenshot 2024-06-10 at 17 45 11"
src="5a766f29-a3b7-40e3-b1f7-8b423073cd87">
##### P.S.
This changes also includes changes to the display of certain panels;
- ML group has a new title i.e. *Machine Learning and Analytics*
- In serverless, the observability panels (SLO*) only shows as a
selection choice in the observability project type.
### Checklist
Delete any items that are not applicable to this PR.
- [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)
<!--
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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] [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] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
<!--
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
-->
---------
Co-authored-by: Catherine Liu <catherine.liu@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/184025
This PR enables the migration from Ace to Monaco in Dev Tools Console by
default in the main branch. All serverless projects will still have the
migration disabled by default. After 8.15 is branched, the migration
will be disabled there as well. The intended release version for this
migration is 8.16.
### Functional tests
This PR creates a copy of functional tests for Monaco Console and keeps
the tests for Ace in a separate folder. When the migration is released,
we can remove the code for Ace together with tests.
The Monaco tests are not the exact copy of the Ace tests, since some
functionality and autocomplete behaviour is slightly different in the
migrated Console. For example, the auto-closing of brackets works in
Monaco when typing something, but is not kicking in in the tests.
Flaky test runner
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Closes https://github.com/elastic/kibana/issues/174745
## Summary
This PR converts Doc Viewer table into EuiDataGrid to use its actions
functionality.
<img width="703" alt="Screenshot 2024-05-17 at 20 18 44"
src="10d8a7b0-8fe1-4908-a11d-5fd374eed4c3">
<img width="577" alt="Screenshot 2024-05-17 at 18 17 49"
src="7e6f05ce-9690-48ab-84c0-f8776e360f83">
<img width="490" alt="Screenshot 2024-05-17 at 18 18 05"
src="b36c64de-419d-425c-9890-8bc346059c1a">
<img width="871" alt="Screenshot 2024-05-22 at 15 22 31"
src="92c894f3-91f8-445c-b6fb-ba8842dd3b23">
## Testing
Some cases to check while testing:
- varios value formats
- legacy table vs data grid
- doc viewer flyout vs Single Document page
### 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
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Andrea Del Rio <delrio.andre@gmail.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
follow up to
https://github.com/elastic/kibana/pull/184777#discussion_r1631353032
Previously, if a user has cloned a dashboard N times, in the worst case
that the next duplication attempt is initiated from the initial
dashboard N network calls would be required to find a unique title for
the next uniquely titled clone. This update short circuits that process
by querying for the last created dashboard, getting it's duplicationId,
increment it and proposing it as the next dashboard duplicate title,
with this approach there's still a chance we might suggest a dashboard
title that's been claimed if the user modifies the dashboard title to a
higher duplication Id after creation, especially that we are querying
for the last created and this is situation we can't correct for, the
resolution for the appropriate title in that case would be on the user.
## How to test
- Create couple of duplicated dashboards, the titles should follow the
normal increment progression ie. n+1
- Create some that skip the expected pattern by any increment of choice,
on attempting to duplicate this dashboard the suggested title should be
previous + 1
- Choose to duplicate any previously created dashboard the suggested
title should be the increment of the last duplicated dashboard
### Checklist
<!-- Delete any items that are not applicable to this PR. -->
<!--
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials -->
- [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
<!--
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
-->
---------
Co-authored-by: Catherine Liu <catherine.liu@elastic.co>
## Summary
Follow up to #180938.
On `Save as`, the suggested title should always be a unique title. I've
added a check for duplicate titles when generating a suggested new
dashboard title. If the dashboards `Dashboard A`, `Dashboard A (1)`, and
`Dashboard A (2)` already exist, the next suggested dashboard title will
be `Dashboard A (3)`. This way the user doesn't end up hitting the
duplicate title warning if they want to quickly clone a dashboard
without updating the title.
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
---------
Co-authored-by: Eyo Okon Eyo <eyo.eyo@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
PR migrates log stream embeddable from the legacy class based system.
### test instructions
1. Run kibana on a system with o11y data and log streams
2. Create a new dashboard, click "Add panel" => "Log stream"
3. Verify panel behavior has not changed with legacy embeddable
4. Click panel context menu and select "Settings"
5. Set custom title, description and time range. Verify behavior has not
changed with legacy embeddable
6. Import dashboard with log stream panel. Verify behavior has not
changed with legacy embeddable
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161047
- Removes the `save as` top nav menu button
- Also renames nav menu item `clone` to `duplicate` and make it
available in edit mode.
- The save dashboard modal no longer displays and open to save the
dashboard in context as new, given that we've chosen to explicitly
create a copy of the dashboard in context when either of the the
`duplicate` or `saveas` menu option is selected.
- includes bug fix for an issue where clicking the dashboard modal
scrolled the user to the content bottom, see
https://github.com/elastic/kibana/pull/180938#issuecomment-2117586572
## Before
### View mode
<img width="1728" alt="Screenshot 2024-04-16 at 15 59 10"
src="48dc4565-1f75-4f46-839c-8d76f4fedefe">
### Edit mode
<img width="1725" alt="Screenshot 2024-04-16 at 15 59 00"
src="1ac743ac-33b4-4f68-ab59-ad19ab58fa1c">
## After
#### Managed Dashboard
5072a501-8d16-4f25-9575-6f11fed6e580
#### View mode
610d0952-97f0-46b8-a0ea-1546a799d387
#### Edit mode
4f596c07-7bd1-4c5a-9131-0c78731cb113
<!-- ### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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)
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/178534
Replaces the pattern analysis flyout in Discover with a tab which sits
alongside the Documents and Field statistics tabs.
**Field selection**
Lists all of the text fields in the index. Auto selects `message`, then
`error.message`, then `event.original` and if none of these fields are
available, it just selects the first field in the list.
The Options menu provides some configuration options:
**Minimum time range**
Sets the minimum time range used for the pattern analysis search. The
pattern matching results results will be more accurate the more data it
sees, so if the user has selected e.g. last 15mins in the time picker,
this settings will ensure a wider time range is used to improve the
accuracy of the patterns. If the time picker has a larger time range
than this setting, the larger time range will be used.
**Random sampling**
Improves the search performance by using a random sampler. This is the
same setting as before.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
## Summary
This PR makes the share redesign modal work the primary share context
paradigm (excluding Canvas) by removing the share plugin config that had
share.new_version.enabled for testing and implementation.
This PR cleans up the FTRs.
Closes [#151523](https://github.com/elastic/kibana/issues/151523)
As a result of defaulting to short urls, some tests were removed since
they are now obsolete.
One fix in this PR to avoid customer known issues is to allow reporting
(if license is permitted) for watcher users. Refer to
https://github.com/elastic/sdh-kibana/issues/4481#issuecomment-2012969470.
I've opened a separate issue to track any skipped or deleted tests as a
result of short urls by default here
https://github.com/elastic/kibana/issues/181066
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
### Release Note
The share menu is updated for a more streamlined user experience. Users
can navigate through a tabbed modal to copy links for discover,
dashboard, and lens.
---------
Co-authored-by: Eyo Okon Eyo <eyo.eyo@elastic.co>
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
Closes: https://github.com/elastic/observability-dev/issues/3353
## Summary
## Description
The Obs Discover view has a datagrid with four (or more) tooltips that
cannot be reached by keyboard. These elements can be helpful to users to
understand what the column represents, and must be available to all
users. Screenshot attached below.
This issue encompasses both the **Discover** and **Logs Explorer** tabs.
There are 4 unique views (2 tabs, 2 sub-tabs each) that have the same
issue. I'm consolidating for speed, but please let me know if you'd
prefer they be broken out to related issues.
### Steps to recreate
1. Open the [Obs Serverless
Discover](https://keepserverless-qa-oblt-b4ba07.kb.eu-west-1.aws.qa.elastic.cloud/app/observability-logs-explorer/)
view
2. Click somewhere close to the datagrid to avoid having to tab through
the entire page
3. Press `Tab` until the datagrid has focus
4. Use the `arrow` keys to traverse the data grid header row
5. Verify the tooltips cannot be reached by`arrow` or `Tab` keypress
### What was done?:
1. Removed `HoverPopover`. The logic might not be suitable for use
outside of the `DataGrid` column.
2. Replaced `EuiToolTip` with `EuiIconTip` for text-based popovers.
3. Refactored `TooltipButton` to properly handle keyboard navigation.
### Screen
9ac9bc70-075f-41f6-a5a5-4e30a385b1c9
## Summary
Updates to the panel title flyout behavior to be more strict about changes to the title, including...
- Input defaults to the actual title when empty (`""`), no longer fills
with default viz `title`/`description`.
- Uses the default title/description when the value is `undefined`, such
that the value has never been set.
- Adds a clear button to the `title` input.
- `Reset` wording replaced with `Reset to default`, for `title` and
`description`.
- Only shows reset if there is a `default` non-empty
`title`/`description` to reset to, applies mostly to by-value viz.
- Changes the inspect panel `title` to always match the panel `title`
and show `"[No Title]"` when empty.
