## 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)
Closes https://github.com/elastic/kibana/issues/208037
This change switches OTel K8S quickstart flow on Serverless to the
managed OTel collector as the ingest endpoint.
* Adds shared `useOtelIngestEndpointUrl` hook to be later re-used in
OTel Host flow as well
* Adds the logic to use APM API key on serverless to access the managed
service endpoint
* Modifies the code snipped with the new variables
## How to test
* Use the Serverless instance deployed from this PR, make sure OTel K8S
flow code snippet uses the managed service endpoint, ingest logs from
your computer (you can use [reference-stack
cluster](https://github.com/elastic/oblt-reference-stack) with minikube)
* Run the classic Kibana locally, and make sure the OTel K8S flow uses
the usual code snippet with ES ingest endpoint, ingest logs from your
computer
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR establishes the baseline to execute Cypress tests in the new
`search_ai_lake` tier.
## Changes Introduced
- All tests under
`x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc` will be
executed using the new tier by default.
- These tests will run as part of the PR process within the `Serverless
AI4DSOC - Security Solution Cypress Tests` execution.
## Adding a New Test
To add a new test, follow these guidelines:
- Read the
[README](x-pack/test/security_solution_cypress/cypress/e2e/ai4dsoc/README.md).
- Inside the `AI4DSOC` folder, we should have different subfolders
representing the various AI4DSOC functionalities.
- Each subfolder should have ownership by either an area team or the
developers actively working on it.
- Make sure that any functionality you want to be tested in the new tier
is added inside the `AI4DSOC` folder; otherwise, that functionality will
be tested using the complete tier.
## Running Tests Locally
Run the tests with the following Yarn scripts from
`x-pack/test/security_solution_cypress`:
```sh
yarn cypress:open:ai4dsoc:serverless
```
Opens the Cypress UI with all tests in the `e2e/ai4dsoc` directory. This
also runs a mocked serverless environment using the `ai_soc` product
line and `search_ai_lake` tier by default.
```sh
yarn cypress:run:ai4dsoc:serverless
```
Runs all tests tagged as @serverless in the e2e/ai4dsoc directory in
headless mode using the ai_soc product line and search_ai_lake tier by
default.
## Key Considerations
- All tests must have the `@serverless` tag to be executed as part of
the PR process.
- MKI is not yet supported for test execution.
- The AI4DSOC Cypress tests will be executed each time there is a change
in one of its
[dependencies](https://github.com/elastic/kibana/blob/main/.buildkite/scripts/pipelines/pull_request/pipeline.ts).
- All tests are executed by default using the `platform_engineer` role.
- Temporary Ownership: The Security Engineering Productivity team will
own the entire AI4DSOC testing folder initially to ensure structure and
best practices. Once all teams understand the workflow, this ownership
will be removed.
- Execution Time: If test execution in a PR takes more than 45 minutes,
parallelism should be increased in the new
`.buildkite/pipelines/pull_request/security_solution/ai4dsoc.yml` file.
## Security Engineering Productivity Codeownership Responsibilities
The Security Engineering Productivity team should ensure:
- Best practices are followed.
- All tests are placed inside a functionality subfolder.
- Each functionality subfolder has designated code owners.
- Tests include the `@serverless` label.
- The execution of AI4DSOC tests does not exceed 45 minutes.
## Follow-Up Tasks
- Remove the dummy test (@tomsonpl feel free to delete it when you need
to add new tests to the navigation).
- Integrate tests into the periodic pipeline.
- Add tests to the Kibana QA quality gate.
- Update the README with MKI instructions once tests are added to the
periodic pipeline and Kibana QA quality gate.
- Clarify which roles will be used for the AI4DSOC effort and update the
tests accordingly.
Adding a link to the stream into the overview tab of the discover
document flyout:
<img width="228" alt="Screenshot 2025-03-12 at 08 57 48"
src="https://github.com/user-attachments/assets/dfd396e7-b0dc-4cca-a09c-637357cc88f9"
/>
Some reviewer notes:
* This is using the same strategy as the observability AI assistant via
the discover_shared registry - streams is not an observability-only
plugin, but for now we want to treat it like this. If we move closer to
this becoming a main feature, we can probably have discover depend on
streams directly
* For now, it's only showing the entry in the flyout if streams is
enabled so it's easy to test but doesn't show up accidentally. Before
the initial release, we can change this condition to always show for
observability spaces
* Resolving an index name to a data stream needs an Elasticsearch call
to get the index meta data. I created a new internal route for that. It
means that there is a loading state in theory, but in practice it should
resolve really quickly because it only hits the cluster state, not the
actual data.
* Even if no stream can be resolved it still shows the entry in the
flyout with a `-`. This is because it avoids shifting layout and it
doesn't seem to hurt if it's there.
* As I need to link to streams, I started introducing a locator - I'm
sure it will be needed more soon. I didn't add all the possible routes
yet, we can expand it as needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to #177932
Inline editing introduced a blurred boundary for the editing experience
in Lens, while the full editor relies on a Redux state manager to
dispatch state changes the inline editor has an hybrid approach.
Specifically the `fixAction` feature in the user messages system needs
access to the redux store which is not available within the embeddable
environment as for now.
So with this PR I've currently limited the scope provided for those
message with a `fixAction` and won't render the button any more.
For instance while investigating #177932 I've noticed that now the
embeddable doesn't crash any more, but rather shows the error message
with the `fixAction` button:
<img width="1496" alt="Screenshot 2025-03-06 at 16 07 35"
src="https://github.com/user-attachments/assets/1b2a5d73-56d9-4010-8a6f-82528efcb2ce"
/>
Note that clicking on the `Use filters` nothing will happen as
d2412a5f98/x-pack/platform/plugins/shared/lens/public/react_embeddable/user_messages/api.ts (L195)
is a mock. A simple `updateAttributes` call here won't suffice as it
requires the logic behind `updateDatasourceState` slice to harmonize the
datasource changes with the visualisation counter part.
With this PR the message will hide the button and render as follow:
<img width="1498" alt="Screenshot 2025-03-06 at 16 18 55"
src="https://github.com/user-attachments/assets/01d55f6c-7563-4e07-a18e-35d1062a8d79"
/>
It is a temporary fix but at least it won't feel broken.
### 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
Closes https://github.com/elastic/streams-program/issues/170 and
https://github.com/elastic/streams-program/issues/171
## Reviewer notes
It's worth reading the research in
https://github.com/elastic/streams-program/issues/168 to understand why
certain decisions were made. Some of the resolving code is inspired by
`grok-js`, unfortunately this wasn't something we could use directly.
The design / UX is **not** final. This is just a functional version. The
editor is currently on the streams > enrichment page so it can be played
with, this will **not** be merged.
There is pattern support for our ECS patterns, I have not added the
legacy ones.
There will almost certainly be some edge cases that don't work, every
repo for a Grok tool I looked at had their own 😅 I've tried to test this
with lots of varied examples though.
I'd recommend unticking "No extension" from the file filter to remove
the pattern files.
<img width="323" alt="Screenshot 2025-03-06 at 22 40 19"
src="https://github.com/user-attachments/assets/5b594f5f-0b0f-4ed0-ae10-2412fcf9e31a"
/>
## Possible improvements / followups
- We could in the future expand the UI to toggle on and off certain
pattern collections.
- Ability to add custom patterns (like in our Grok debugger). This can
still be achieved with `(?<queue_id>[0-9A-F]{10,11})` syntax.
- Point out when regex is invalid (right now it's silent).
- I've copied over the patterns from the ES repo for now, with a light
script to generate an object from them. There's a CLI skeleton in place
if we feel we want to actually pull these from the ES repo directly.
These patterns don't change often, and aren't heavy size wise.
- Debouncing etc for processing, but I'd like to see how the final UX
ends up.
## Media
Screenshot
Simple example
Complex example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
More teams are adding Scout tests in their plugins, often as a PoC and
not stable yet for continuous execution.
We don't want to block it, but need a way to manage the scope of Scout
pipeline and be able to disable it quickly to unblock the Scout
development.
Since Scout is in active development and we need it to be simple and
quick as possible (we can iterate and improve later), we agreed with
Robert to disable tests by plugin:
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
- observability_onboarding
disabled:
- *skipped_plugin*
```
When scout configuration is added to the new plugin, it will require to
update `.buildkite/scout_ci_config.yml` that is owned by `appex-qa`
team. If there is no intention to run Scout tests on CI, plugin name
should be added under `disabled` section.
**How to test locally:**
- Scout tests were added in `observability_onboarding` plugin, pipeline
will throw error
modify locally `.buildkite/scout_ci_config.yml`
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
disabled:
```
run `node scripts/scout discover-playwright-configs --validate --save`
```
ERROR The following plugins are not registered in Scout CI config '.buildkite/scout_ci_config.yml'
- observability_onboarding
```
~~On CI annotation will be added to clarify the failure:~~
we decided to move validation to "Quick Checks", no need to annotate.
<img width="1583" alt="image"
src="https://github.com/user-attachments/assets/ed6b5778-74cb-4473-8218-b96239aab067"
/>
- `observability_onboarding` plugin is disabled, pipeline won't include
it (excluded in `scout_playwright_configs.json`)
modify locally `.buildkite/scout_ci_config.yml`
```
ui_tests:
enabled:
- apm
- discover_enhanced
- maps
disabled:
- observability_onboarding
```
run `node scripts/scout discover-playwright-configs --validate --save`
```
warn The following plugins are disabled in '.buildkite/scout_ci_config.yml' and will be excluded from CI run
- observability_onboarding
info Found Playwright config files in '4' plugins.
Saved '3' plugins to '/Users/dmle/github/kibana/.scout/test_configs/scout_playwright_configs.json'
```
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `66d427a` ->
`5ba5def` |
---
### 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>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: drewdaemon <drew.tate@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Resolves#212981
## Release Notes
Adds the ability to create an APM availability or latency SLO for all
services
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Kevin Delemme <kdelemme@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/214709#event-16799922233
The issue was caused by the rollover of the Knowledge Base Data stream
to use default inference endpoint.
During the rollover it first got to this branch
https://github.com/elastic/kibana/blob/main/x-pack/solutions/security/plugins/elastic_assistant/server/ai_assistant_service/index.ts#L347-L369
where it went through all the steps and continued, but it didn't
override `this.knowledgeBaseStream`, so the next time someone hit API it
was going through this path calling `getInitializedResources` to make
sure all data streams were configured properly, but because we didn't
update `this.knowledgeBaseStream` it was failing, because the original
configuration that was created in service constructor was not called,
that's why it was returning an error
### Authz API migration for unauthorized routes
This PR migrates last 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);
```
## Summary
Resolves https://github.com/elastic/kibana/issues/213629.
Since https://github.com/elastic/kibana/pull/163784 we have included a
`format` parameter in the `sort` that we send to Elasticsearch. This
worked for everything except rollup data views, which break when the
`format` parameter is provided.
This restores the behavior prior to that PR (we still send the `sort`
but don't include the `format` parameter). Ideally we would probably not
send the timestamp field at all for rollup data views since we treat
them as if they are non-time-based, but this would require a bit of a
refactor, and rollups are deprecated anyway.
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### Release notes
Fixes opening a rollup data view in Discover.
Co-authored-by: Matthew Kime <matt@mattki.me>
### Authz API migration for unauthorized routes
This PR migrates last 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);
```
Not sure whether we have an issue for is, but a problem I constantly run
into is that cmd+click to open in new tab doesn't work with the new side
nav. You need to do right click + open in new tab which is taking at
least 3 times as long.
This is a problem because it's not the expected behavior - the entries
in the nav are regular links and they should behave like that (the old
nav didn't have this problem).
This PR fixes the issue to not call `e.preventDefault()` in case it's a
"special click" and only triggers the in-page navigation in cases where
the user does a normal left click.
Co-authored-by: Bhavya RM <bhavya@elastic.co>
