## Summary
Changed import path for Kibana Core Public imports, previous was not
working. New import path reflects what I found elsewhere in the
codebase, and works.
Fixes https://github.com/elastic/kibana/issues/196331
## Summary
This PR fixes the bug in the Edit ds data retention modal where we were
comparing the max retention period with an undefined `value` (now the
comparison happens only if `value` is defined). Also, the PR makes the
data retention field get re-validated only when the time unit changes
(otherwise, when we switch off the toggle to enable to data retention
field, the field would get validated and would immediately show an error
"A data retention value is required." which is not great UX).
### How to test:
1. Start serverless ES with `yarn es serverless --projectType=security
-E data_streams.lifecycle.retention.max=200d` and kibana with `yarn
serverless-security`
2. Navigate to Kibana, create a data stream using Dev Tools:
```
PUT _index_template/ds
{
"index_patterns": ["ds"],
"data_stream": {}
}
POST ds/_doc
{
"@timestamp": "2020-01-27"
}
```
3. Navigate to Index Management. Find the data stream and select it -->
Click "Manage" --> Click "Edit data retention"
4. Disable the toggle "Keep data up to maximum retention period"
5. Verify that the field is enabled correctly, there is not endless
spinner, and no console error.
https://github.com/user-attachments/assets/957e0869-ee23-46d9-8f20-134937f6f8cf
---------
Co-authored-by: Matthew Kime <matt@mattki.me>
## Summary
Closes https://github.com/elastic/kibana/issues/197091
This PR uses the previously created
(https://github.com/elastic/kibana/pull/194419) subfeature permissions
for APM to be able to modify settings inside Labs flyout.
## Screenshots for unauthorized user
| Before | After |
|-------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
||
## How to test
1. Go under Stack Management -> Roles and create a new custom role.
2. For Kibana, select All spaces for the space selector, and Customize,
you can get all the permissions you need.
3. Go into Observability and APM and User Experience.
4. Select Read and save the role.
5. Create a new user and assign that role and also the viewer role.
6. Login with an incognito / different browser into the new user.
7. Go into APM -> Settings, WARNING: if you are not able to see settings
is because you don't have data, run node scripts/synthtrace
many_services.ts --live --clean.
8. You should not be able to change the configuration on each tab.
9. Change the role privileges to have Read but with write access.
10. Test it, you should be able to modify the settings.
11. Do the same with All with and without the write permissions.
## Summary
Currently all notes that make use of the markdown based timeline data
providers will render as a timeline template if the note is associated
with an event, and not an alert. Mostly everything is in place to have
everything work for both already, there's just no context that contains
the event document in the tree in the notes list component currently.
This pr adds that context, and everything else works as expected.
### 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
Closes https://github.com/elastic/kibana/issues/197192
- Alert event is shown as per "alert start" time
- Events are filtered by the alert group/source information (For now,
only filtering by `service.name` for the demo. We need to change the
logic to use `OR` when applying filter for group-by fields)
- Fixed rule condition chart on investigation page when "rate"
aggregation is used
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Fixes https://github.com/elastic/kibana/issues/182017
## Summary
The PR tries to address the flakiness from the test.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/196506
## Summary
Before linking to Logs Explorer in Dataset Quality, the PR checks if
`observability-logs-explorer` is available and accessible before
consuming the `SINGLE_DATASET_LOCATOR_ID` locator.
Observability Logs Explorer app is not available in Security and Search
solution views.
After the fix:
https://github.com/user-attachments/assets/ed36806a-0483-4765-a6f1-85936b92d390
There's only one more place, Observability Onboarding, where
`SINGLE_DATASET_LOCATOR_ID` is consumed. Which being part of
Observability solution view, it can be assumed that Observability Logs
Explorer will always be available.
----
The other Observability Logs Explorer locator `ALL_DATASETS_LOCATOR_ID`
is only consumed in observability wrapper apps and `apm` and `infra`
plugins, all of which are only available under Observability where
Observability Logs Explorer is also available.
68b3267ca2/packages/deeplinks/observability/locators/observability_logs_explorer.ts (L24)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Chromedriver is currently downloaded at runtime on each agent. We know
the expected version of Chrome at image build time, and can re-use the
matching driver already installed instead.
This sets `XDG_CACHE_HOME` to `$HOME/.cache` to persist the chromedriver
installation. Details on the specification can be found at
https://specifications.freedesktop.org/basedir-spec/latest/. Other
packages, including cypress, playwright, bazelisk and yarn also respect
this environment variable, but are already falling back to the
`$HOME/.cache` directory.
This also removes `CHROMEDRIVER_FORCE_DOWNLOAD`, which I believe is an
artifact of legacy code:
https://github.com/elastic/kibana/blob/6.7/.ci/packer_cache.sh#L17-L26.
At one point node_modules was initially loaded from an archive to speed
up bootstrap times. The intent was to redownload chromedriver because
the Chrome version on the agent image was upgraded independently of the
bootstrap cache, potentially causing version mismatches. The impact of
re-downloading was also less significant, as there was less
parallelization in favor of large machines running parallel jobs.
## Summary
Addresses https://github.com/elastic/kibana-team/issues/1175
As part of the **Sustainable Kibana Architecture** initiative, this PR
sets the foundation to start classifying plugins in isolated groups,
matching our current solutions / project types:
* It adds support for the following fields in the packages' manifests
(kibana.jsonc):
* `group?: 'search' | 'security' | 'observability' | 'platform' |
'common'`
* `visibility?: 'private' | 'shared'`
* It proposes a folder structure to automatically infer groups:
```javascript
'src/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'src/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/platform/plugins/shared': {
group: 'platform',
visibility: 'shared',
},
'x-pack/platform/plugins/internal': {
group: 'platform',
visibility: 'private',
},
'x-pack/solutions/observability/plugins': {
group: 'observability',
visibility: 'private',
},
'x-pack/solutions/security/plugins': {
group: 'security',
visibility: 'private',
},
'x-pack/solutions/search/plugins': {
group: 'search',
visibility: 'private',
},
```
* If a plugin is moved to one of the specific locations above, the group
and visibility in the manifest (if specified) must match those inferred
from the path.
* Plugins that are not relocated are considered: `group: 'common',
visibility: 'shared'` by default. As soon as we specify a custom
`group`, the ESLINT rules will check violations against dependencies /
dependants.
The ESLINT rules are pretty simple:
* Plugins can only depend on:
* Plugins in the same group
* OR plugins with `'shared'` visibility
* Plugins in `'observability', 'security', 'search'` groups are
mandatorily `'private'`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added documentation for the security route configuration.
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Fixes#196286
Updated the documentation link in the footer of the create visualization
modal.
The `getDocLinks` guide link under "visualize" previously pointed to
dashboard.html, it's now corrected to _panels_and_visualizations.html.
This also affected a documentation link elsewhere, as seen in the
screenshot.
Reverted it back using the "dashboard" guide link which also points to
dashboard.html since the issue specified changing only the create
visualization modal doc link.
https://github.com/user-attachments/assets/af6a4993-aac3-446f-8228-d0fe89d97cb2
---------
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/196303
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
visualize app - new charts library visualize area charts date histogram
when no time filter interval errors should show error when calendar
interval invalid.
[Failure](https://buildkite.com/elastic/kibana-pull-request/builds/236562#019222ec-e8d1-4465-ada3-fd923283b6f4)
----
I investigated the problem and understand what is not working and
suggesting this simple fix, but open to any other approaches or
suggestions.
To Reproduce the failing tests:
1. Create aggregation based viz, e.g. Area Chart
2. Add data histogram agg
3. Change minimum interval to a invalid value (for example, "f")
4. Change minimum interval to another invalid value ("ff")
React@18 failure:
https://github.com/user-attachments/assets/f8684b48-fb24-4500-a762-2a116ed55297
The error is thrown from here in the reducer:
23e0e1e61c/src/plugins/vis_default_editor/public/components/sidebar/state/reducers.ts (L82)
When we try to update the state using 2nd invalid value, the error is
thrown when we try to serialize the current agg with previous invalid
value.
This code is exececuted when we call `agg.serialize`:
5ed6981828/src/plugins/data/common/search/aggs/buckets/lib/time_buckets/time_buckets.ts (L200-L202)
**Why don't we see this failure in React@17?**
In React@17 we don't see an error screen, but we only see a log in the
console.
> TypeError: "f" is not a valid interval.
It turns out that React@17 consistently executed that reducer twice.
first time during dispatch and second time during rendering. This
shouldn't be a problem because reducers are supposed to be pure (without
side-effects). **But in this case calling `agg.serialize` only throws an
error when called the first time**! So in React@17 the reducer was
called the first time, the error was swallowed, then it was called the
2nd time and, since the `TimeBucket` was cached, there was no error
anymore, so it never bubbled up during rendering.
The root cause of inconsitent behaviour is here:
8afbbc0082/src/plugins/data/common/search/aggs/buckets/date_histogram.ts (L111-L121)
when `get()` called first time we create buckets and cache them. but we
cache them before calling `updateTimeBuckets` which is where the error
happens.
To fix this issue, we should make the reducer pure. One approach is to
swallow that error so that the call to `agg.serialize()` is consistent.
Another approach could be to always throw that error, but then a larger
refactor is needed and this likely a more risky and impactfull change.
## Summary
This PR fixes a bug which caused mixed case tags to not be found in
global search.
Fixes: #196168
The `allTags` argument contains tags with names in the original case
they were created but the `tagName` argument passed in
[search_bar.tsx:180](https://github.com/elastic/kibana/blob/main/x-pack/plugins/global_search_bar/public/components/search_bar.tsx#L180)
is lowercase. Since you can't have tags with the same name but different
casing, converting them to lowercase is safe.
I've also added lowercase conversion to `tagName` argument in case this
function gets called somewhere else and the input is not lowercase.
## Summary
Skips the functional test for the org members management nav card on
MKI. The test attempts to confirm a link to the cloud org members page,
but on MKI it will redirect to cloud login.
## Summary
To ensure that `no_deprecated_authz_config` rule is only applied during
an intentional migration, added check for env vars presence.
If neither `MIGRATE_ENABLED_AUTHZ` nor `MIGRATE_DISABLED_AUTHZ` is set,
the rule will be skipped, avoiding unnecessary or unforeseen code
changes both locally and in the CI.
Added fix and test case for `access:${APP.TEST_ID}` tags that have
property access in the template literal.
__Closes: https://github.com/elastic/kibana/issues/196846__
### 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
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Update the entity store API so it does not return the asset criticality
field when the value is 'deleted'.
### How to test it
* Open kibana with data
* Install the entity store
* Update asset criticality for a host or user
* Wait for the engine to run (I don't know a reliable way to do this)
* Refresh the entity analytics dashboard, and it should show empty
fields for deleted asset criticality
- [ ] Backport it to 8.16
### 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
Related to #181828
## Summary
This PR refactors the custom threshold app section to rely on the alert
rule params instead of rule params.
### How to test
- Create a custom threshold rule and verify that the alert details page
works as before
- Also, check the log rate analysis component and ensure it works as
before
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.
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [msw](https://mswjs.io) ([source](https://togithub.com/mswjs/msw)) |
devDependencies | patch | [`^2.4.10` ->
`^2.4.11`](https://renovatebot.com/diffs/npm/msw/2.4.11/2.4.11) |
`2.4.12` |
---
### 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://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNsb3VkIFNlY3VyaXR5IiwiYmFja3BvcnQ6c2tpcCIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change | Pending |
|---|---|---|---|---|
| [msw](https://mswjs.io) ([source](https://togithub.com/mswjs/msw)) |
devDependencies | patch | [`^2.4.9` ->
`^2.4.10`](https://renovatebot.com/diffs/npm/msw/2.4.9/2.4.10) |
`2.4.11` |
---
### Release Notes
<details>
<summary>mswjs/msw (msw)</summary>
### [`v2.4.10`](https://togithub.com/mswjs/msw/releases/tag/v2.4.10)
[Compare
Source](https://togithub.com/mswjs/msw/compare/v2.4.9...v2.4.10)
#### v2.4.10 (2024-10-11)
##### Bug Fixes
- **setupWorker:** perform worker update in the background
([#​2311](https://togithub.com/mswjs/msw/issues/2311))
([`8e40724`](8e40724cd3))
[@​kettanaito](https://togithub.com/kettanaito)
</details>
---
### 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://togithub.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM3LjQyNS4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNsb3VkIFNlY3VyaXR5IiwiYmFja3BvcnQ6c2tpcCIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
---------
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
Closes https://github.com/elastic/kibana/issues/192811
## Summary
When creating a space, if it's not the current, you should be able to
use the switch icon from the table. This PR fixes a bug that disabled
the switch icon for spaces that aren't the current, if they have the
same name as the current.
### 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
Fixes https://github.com/elastic/kibana/issues/195877
Addresses https://github.com/elastic/kibana/issues/179658
## Summary
This PR fixes the bug in Console where using the `load_from` param in
the URL made Console uneditable because every re-render reset the
initial value in the editor. This is fixed by restricting the hook to
only set the initial value once. This PR also adds some unit tests for
the hook, as I realized that this was a long-standing improvement.
### How to test:
Try loading the following URL (making the necessary replacement in the
URL) and verify that the data is correctly loaded into the editor and
value can be edited:
`http://localhost:5601/<REPLACE-THIS>/app/dev_tools#/console?load_from=data:text/plain,AoeQygKgBA9A+gRwK4FMBOBPGBDAzhgOwGMB+AEzQHsAHOApAGwbiMoaQFsDcAoAbx5QoAImToMwgFwiAZgCVKAWShoUHSgBcUAWgBUkgJYEyKAB4pcwgDSCRDSkWwMUUkSgLXbwmQYZa0rgJCQsIARpRsgbbBIhxIuBquANoAujYxIT5+6Mlp0cHCuAAWlIxkuekZwnEJdJq5+QC+ts2NQA`
`http://localhost:5601/<REPLACE-THIS>/app/dev_tools#/console?load_from=https://www.elastic.co/guide/en/elasticsearch/reference/current/snippets/86.console`
Co-authored-by: Matthew Kime <matt@mattki.me>
