## Summary
Resolves#201442.
The underlying issue is that `isEnabledAtPath` validates the entire
config object when it only cares about `.enabled`. This PR performs that
check using `stripUnknownKeys: true`, as we'll perform the actual
validation later on.
### 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
- update data_streams route to accept includeZeroStorage flag to make
testing easier. the metering api only collects data once every 30s and
that might be changed to being longer so we can't wait for data to be
aggregated. We can potentially surface this option to the user in the
future.
- unskip data stream api test. will enable in MKI after manual
confirmation it passes with a followup PR.
---------
Co-authored-by: Ash <1849116+ashokaditya@users.noreply.github.com>
### 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: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Lukas Olson <lukas@elastic.co>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
## Summary
In order to show all potential deprecations, the SO request should
include all spaces by appending `namespaces: ['*']`.
This PR adds that, although it doesn't change the test (which, IMO,
should include the offending space). Feel free to commit to this PR or
to create a follow-up (whatever you prefer).
Related: https://github.com/elastic/kibana/issues/202341
Closes: #202427
## Description
Dialog modal visible title should be announced for the users, especially
using assistive technology to know what dialog modal, flyout opened.
## Changes made:
1. aria-labelledby={modalTitleId} attribute was added for mentioned
EuiModal
## Screen
<img width="1135" alt="Screenshot 2024-12-02 at 14 43 16"
src="https://github.com/user-attachments/assets/ce319c22-1ae9-49e1-99e1-7670e5d97993">
## Summary
Fixes https://github.com/elastic/kibana/issues/200899
Added Synthetics Sub-feature for managing private locations !!
User can configure a sub feature in a role under synthetics to allow
managing private locations ,
with role API it will be with
```
{
kibana: [
{
feature: {
uptime: [
'minimal_all',
'can_manage_private_locations',
],
},
spaces: ['*'],
},
],
}
```
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/f842da22-9c82-43d0-ad34-c6e19ea187c6">
Create/delete actions on UI will be disabled
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/1a164d85-357b-42f3-ae15-0682b2db6c75">
## Release note
If you have already modified sub feature for the synthetics/uptime
feature to disable user access for using elastic managed location,
addition of this feature means, they will also will not be able to
manage(add/delete) private locations. Though this will not impact usage
of private locations in monitors. If you want those users to have
ability to add/delete new private locations, you can enable that by
toggle this feature in role ui or via api.
## Summary
@markov00 opened PR to
[migrate](https://github.com/elastic/kibana/pull/201105) from `faker`,
but it probably will take extra time and to keep track let's move its
ownership to `team:kibana-visualizations`
---------
Co-authored-by: Marco Vettorello <vettorello.marco@gmail.com>
## Summary
This PR updates some dev dependencies owned by appex-qa.
[PR](https://github.com/elastic/kibana/pull/200791) by renovate is
trying to update to many things at once 🚋
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
I noticed that I was not able to clear the user-specific system prompt.
I had initially entered "Please speak in Swedish" and saved. Afterwards
I wanted to clear this but the save button is disabled if the text
content is empty.
## Summary
Part of the resolution of this issue:
- https://github.com/elastic/kibana/issues/149246
Removes the `style` prop in React components and elements to avoid using
inline styles. Instead, it uses now the `emotion.css` prop to
dynamically attach all styles to the native `class` attribute.
### Motivation
Using inline styles at scale causes a performance penalty at rendering
time. It's way more efficient to attach styles to a single or several
classnames instead.
### How to review
From [Emotion's official
docs](https://emotion.sh/docs/css-prop#style-precedence):
> [!NOTE]
> Any component or element that accepts a `className` prop can also use
the `css` prop. The styles supplied to the `css` prop are evaluated and
the computed class name is applied to the `className` prop.
Components that are safe to migrate from `style` to `css`:
- React elements
- React components exposed by EUI (they all support a `className` prop
and the [Babel
plugin](https://www.npmjs.com/package/@emotion/babel-preset-css-prop) is
enabled throughout Kibana)
Components where styling might break:
- Custom component we wrote that currently don't accept a `className`
prop.
- Specific 3P components that pass in a `style` prop to our components
i.e. `react-window` (it calculates the dynamic position of all
virtualized elements and hides the ones outside the visible fold)
- Specific 3P components that expect a `style` prop to be styled i.e.
charts, etc.
### 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] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [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)
### Identify risks
Main risk is breaking the UI by not applying or incorrectly applying the
styling. This was explained in the "How to review" section above. The
risk has **low severity** though. The mitigation plan will simply be
reverting the commit asap not to affect production and test locally
until it's fixed./
## Summary
Fixes#199736
This PR exposes the `parentApi` when it satisfy the
`PresentationContainer` type: this allows api consumers (i.e. dashboard
actions) to access the full container context for complex evaluation of
an action (i.e. are there other panels? what types are they made of?
etc...).
I've limited it to `PresentationContainer` as this was the original
intent of the feature request (and avoids type casting). If it needs to
be extended more another follow up can be done.
Part of https://github.com/elastic/ingest-dev/issues/4517
Closes https://github.com/elastic/kibana/issues/167160
## Summary
Replace `promise.all` with `pMap` across Fleet. The reason for this
refactor is introducing concurrency control in those cases when we are
running multiple requests towards ESclient.
Most of the refactor in this PR occurs around the packages install area,
as packages can have high numbers of assets, data streams or backing
indices so I focused on addressing those.
### Checklist
Check the PR satisfies following conditions.
- [ ]
[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
- [ ] 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
As this PR can have impacts in key areas of Fleet (package installs,
policies etc), I'm not going to merge right away but I'll take some time
to test properly and I'll merge next week.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
resolves https://github.com/elastic/kibana/issues/159454
Remove experimental message from saved objects import and export apis.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## 📓 Summary
Closes#198849Closes#200287Closes#201273Closes#201975
The above issues were raised with similar conditions which converged in
the following assumptions:
- They are raised due to timeout identifying a visual element on the
degraded fields flyout.
- They are raised due to a missing UI element, which is part of a common
sub-tree conditionally rendered when the data analysis is completed.
- They are raised in serverless tests, where the latency might be
randomly higher.
Given the nature of these tests, which locally always pass correctly
given the fastest nature of a local setup, I assume these random
failures are due to latency on the common request gating the rendering
of these sections.
As a fix, I added a wait on the global loading indicator before the
assertions, which should wait for the data loading to be completed
before running the assertions on the UI elements.
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
## Summary
Add quick check to prevent test files from being added without an owner
Resolves: #192979
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Robert Oskamp <robert.oskamp@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/191812
Adds ability to create ES|QL AST nodes from plain strings and compose
them.
Create an integer literal:
```js
const node = expr `42`;
```
Create any expression:
```js
const node = expr `nested.field = fn(123)`;
```
Compose AST nodes:
```js
const value = expr `123`;
const node = expr `nested.field = fn(${value})`;
```
## Usage
You can create an assignment expression AST node as simle as:
```ts
import { synth } from '@kbn/esql-ast';
const node = synth.expr `my.field = max(10, ?my_param)`;
// { type: 'function', name: '=', args: [ ... ]}
```
To construct an equivalent AST node using the `Builder` class, you would
need to
write the following code:
```ts
import { Builder } from '@kbn/esql-ast';
const node = Builder.expression.func.binary('=', [
Builder.expression.column({
args: [Builder.identifier({ name: 'my' }), Builder.identifier({ name: 'field' })],
}),
Builder.expression.func.call('max', [
Builder.expression.literal.integer(10),
Builder.param.named({ value: 'my_param' }),
]),
]);
// { type: 'function', name: '=', args: [ ... ]}
```
You can nest template strings to create more complex AST nodes:
```ts
const field = synth.expr `my.field`;
const value = synth.expr `max(10, 20)`;
const assignment = synth.expr`${field} = ${value}`;
// { type: 'function', name: '=', args: [
// { type: 'column', args: [ ... ] },
// { type: 'function', name: 'max', args: [ ... ] }
// ]}
```
Use the `synth.cmd` method to create command nodes:
```ts
const command = synth.cmd `WHERE my.field == 10`;
// { type: 'command', name: 'WHERE', args: [ ... ]}
```
AST nodes created by the synthesizer are pretty-printed when you coerce
them to
a string or call the `toString` method:
```ts
const command = synth.cmd ` WHERE my.field == 10 `; // { type: 'command', ... }
String(command); // "WHERE my.field == 10"
```
## Reference
### `synth.expr`
The `synth.expr` synthesizes an expression AST nodes. (*Expressions* are
basically any thing that can go into a `WHERE` command, like boolean
expression,
function call, literal, params, etc.)
Use it as a function:
```ts
const node = synth.expr('my.field = max(10, 20)');
```
Specify parser options:
```ts
const node = synth.expr('my.field = max(10, 20)', { withFormatting: false });
```
Use it as a template string tag:
```ts
const node = synth.expr `my.field = max(10, 20)`;
```
Specify parser options, when using as a template string tag:
```ts
const node = synth.expr({ withFormatting: false }) `my.field = max(10, 20)`;
```
Combine nodes using template strings:
```ts
const field = synth.expr `my.field`;
const node = synth.expr `${field} = max(10, 20)`;
```
Print the node as a string:
```ts
const node = synth.expr `my.field = max(10, 20)`;
String(node); // 'my.field = max(10, 20)'
```
### `synth.cmd`
The `synth.cmd` synthesizes a command AST node (such as `SELECT`,
`WHERE`,
etc.). You use it the same as the `synth.expr` function or template
string tag.
The only difference is that the `synth.cmd` function or tag creates a
command
AST node.
```ts
const node = synth.cmd `WHERE my.field == 10`;
// { type: 'command', name: 'where', args: [ ... ]}
```
### Checklist
Delete any items that are not applicable to this PR.
- [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
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
## Summary
This enables the knowledge base for the Serverless Search AI assistant.
It also renames a few options to align naming, including a rename for
the settings page in Observability's Serverless deployment to remove a
reference to Search.
## Summary
Implements
https://github.com/elastic/logs-dev/issues/111#issuecomment-2446470635.
This adds a new "Saved Search component". The component is a wrapper
around the current Saved Search Embeddable, but uses
`ReactEmbeddableRenderer` directly to render the embeddable outside of
Dashboard contexts. It monitors changes to things like `index`,
`filters` etc and communicates these changes through the embeddable API.
For this PoC two locations were changed to use this component 1) Logs
Overview flyout 2) APM Logs tab (when the Logs Overview isn't enabled
via advanced settings).
The component itself is technically beyond a PoC, and resides in it's
own package. ~I'd like to get eyes from the Discover folks etc on the
approach, and if we're happy I can fix the remaining known issues (apart
from the mixing of columns point as I believe this exists on the roadmap
anyway) and we can merge this for the initial two replacement points.~
[Thanks Davis
👌](https://github.com/elastic/logs-dev/issues/111#issuecomment-2475350199).
`nonPersistedDisplayOptions` is added to facilitate some configurable
options via runtime state, but without the complexity of altering the
actual saved search saved object.
On the whole I've tried to keep this as clean as possible whilst working
within the embeddable framework, outside of a dashboard context.
## Known issues
- ~"Flyout on flyout" in the logs overview flyout (e.g. triggering the
table's flyout in this context).~ Fixed with `enableFlyout` option.
- ~Filter buttons should be disabled via pills (e.g. in Summary
column).~ Fixed with `enableFilters` option.
- Summary (`_source`) column cannot be used alongside other columns,
e.g. log level, so column customisation isn't currently enabled. You'll
just get timestamp and summary. This requires changes in the Unified
Data Table. **Won't be fixed in this PR**
- We are left with this panel button that technically doesn't do
anything outside of a dashboard. I don't *think* there's an easy way to
disable this. **Won't be fixed in this PR**
## Followups
- ~The Logs Overview details state machine can be cleaned up (it doesn't
need to fetch documents etc anymore).~ The state machine no longer
fetches it's own documents. Some scaffolding is left in place as it'll
be needed for showing category details anyway.
## Example
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- This pull request resolves
[elastic/kibana#200881](https://github.com/elastic/kibana/issues/200881)
by setting a min-width of 10px for the DistributionBar component to
prevent it from shrinking too small, ensuring a consistent and readable
visual representation for better usability.
- Additionally, added a README file with instructions for running
Storybook to visually inspect the DistributionBar, as the folder had no
documentation before, improving the developer experience.
## Screenshots:
**Before**
- The min-width of 10px was set, but small segments were not visible in
the DistributionBar.
- The original mockStatsFindings with 'passed' set to 90 and 'failed'
set to 10 did not visually reflect the min-width of 10px in the
DistributionBar. The smallest segment was still not visible.
**After**:
- Temporarily modified the `mockStatsFindings` in
`distribution_bar.stories.tsx` to simulate the DistributionBar with
extreme values by setting the count for 'passed' to 9000 (highest) and
'failed' to 1 (lowest):
- After the modification, the DistributionBar displayed correctly with
even the smallest segments visible, confirming that the min-width is
working as expected.
- These results were captured in a screenshot for the PR, and no changes
were saved to the `distribution_bar.stories.tsx` file.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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)
