Adds the ability to quickly create a categorisation anomaly detection
job from the pattern analysis flyout.
Adds a new `created_by` ID `categorization-wizard-from-pattern-analysis`
which can be picked up by telemetry.
Creates a new package for sharing our AIOPs ui actions IDs. I think we
should move the pattern analysis ID to this package too, but that can be
done in a separate PR.
51349f93-f072-4983-85f0-98741902fb5a
6e618581-8916-4e63-930f-945c96c25e6c
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/170758
This PR increases root breadcrumb max width from 160 to 320px to fit
more of project titles. It also slightly adjusts number of visible
breadcrumbs per breakpoint to account for potentially 2x longer root
breadcrumb. Note that responsiveness is still not ideal as the system
doesn't actually calculate the width of each breadcrumb.
Before:
<img width="1267" alt="Screenshot 2023-11-20 at 11 53 13"
src="6d2ba8d2-5bc0-4f85-a87a-a4185ae901f7">
After:
<img width="1284" alt="Screenshot 2023-11-20 at 11 52 31"
src="90a57e58-6836-4465-a21e-78f72dc4953e">
## Summary
Update new user details flyout to be consistent with Expandable Alerts
Flyout. The previous user details flyout implementation was hidden
behind a flag and never went live.
### What is included
* Update new user details flyout to use the expandable flyout component
* Update UI components according to the new design
* Keep the feature hidden behind newUserDetailsFlyout flag
* Supporting alert risk inputs
### What is NOT included
* Supporting multiple categories of risk inputs
* Host details flyout
* User and host pages
* Asset integrations (okta and azure)
* Update the flyout on the timeline (It is currently a technical
restriction of the expandable flyout, but the team is working to fix it)
### How to test it?
* Enable experimental flag `newUserDetailsFlyout`
`xpack.securitySolution.enableExperimental: ['newUserDetailsFlyout']`
* Create alerts and open alerts page
* Click on a username
- [x] Test edge cases
- [x] No cases permissions (it hides cases actions)
- [x] Basic license (it hides the risk score summary)
- [x] No risk score data for a user (It hides the risk score summary)
<img width="434" alt="Screenshot 2023-11-13 at 15 56 33"
src="4fc13042-cd3d-487b-9982-bfbf02f003b4">
### 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))
Fixes https://github.com/elastic/kibana/issues/168349
## Summary
Fix links to Logs view to point to Discover in Serverless.
As the Logs view UI is not available in serverless, the "Open in logs"
buttons should point to Discover instead. Rather than hardcode the url
in each of the places where is needed, I extracted a small component
that builds the two urls and allows switching in an easier way.
If in the future on of the two links will go away, it will be easier to
find those occurrences.
### Testing
Test for serverless following [these
instructions](https://github.com/elastic/kibana/pull/167976)
**Error logs in agent activity flyout**
- Enroll an agent and try to cause some error - for instance upgrading
an agent that is not upgradeable
- Click on "Agent Activity" and find the error and a button besides it
- On stateful the button says "Open in Logs"
- On serverless is "Open in discover"
- Check that both show the same logs:
**Agent logs**
(Same test as above)
- Enroll an agent
- Click on the agent and go to the "Logs" tab
- On stateful the button says "Open in Logs"
- On serverless is "Open in discover"
- Check that both show the same logs
**Custom Logs UI**
There is also a link to logs on custom logs UI but I just linked to
discover for that one:
https://github.com/elastic/kibana/pull/171525/files#diff-e337aa916d60d0d1033e3298c8c9c33c6a6fcd87a8ded971a4a87f5ccfc0981fR20-R22
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Currently Findings and Dashboard page kept showing data even if the data
past its retention period. This PR will make it so that, it will only
show data within that retention period, If theres no more data past that
retention period it will show No Agent deployed prompt instead
Our solution/workaround for this will be adding a retention periods for
each kind of posture type:
**KSPM** and **CSPM** : 26 hours
**CNVM** and **all** : 3 days or 72 hours
if posture type doesnt exist : 72 hours (this is to cover the situation
where findings came before CSPM gets implemented back then)
Before when having Findings outside retention period:
<img width="1391" alt="Screenshot 2023-11-07 at 5 03 15 PM"
src="26f74ebf-8002-4da9-b4f1-8238e81cea5e">
After: (27 hours later)
<img width="1452" alt="Screenshot 2023-11-07 at 4 52 09 PM"
src="98a33379-dc21-4edf-97b6-32de584598e9">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/25117
## Summary
Add a missing transaction warning if there are Transactions or Spans
with a `parent.id` that doesn't exist in the trace.
## Testing
- Use the `trace_with_orphan_items.ts` scenario: `node
scripts/synthtrace --clean trace_with_orphan_items.ts`
- In APM -> Traces there are 2 traces:
- <img width="1423" alt="image"
src="3548d1dd-d87f-4090-a028-d62cf8ec35c8">
- Check the traces:
- Incomplete trace (with warning):
- <img width="1401" alt="image"
src="a75a2112-a425-43d9-bdd1-b3724ccfe6e3">
- Complete trace (no warning):
- <img width="1387" alt="image"
src="f33614ab-269b-447c-bd0b-bc00f9799092">
- Unit test in
[waterfall_helpers.test.ts](https://github.com/elastic/kibana/pull/171196/files#diff-6cdeaa931c0085a16353ac34f937d442a39e1227621f11b3de0608a39e949fc6)
## 📓 Summary
Closes#170728
This work comes from the need to use agent and cloud provider icons in
the new Log Detail flyout.
Since those icons were already used across the `infra` and `apm`
plugins, this was a good opportunity to extract the shared logic into
packages.
The results of this refactoring are two new packages:
- **@kbn/elastic-agent-utils**: exports small utilities and type
definition used to parse the icon to render and exploits also across the
APM plugin.
- **@kbn/custom-icons**: exports custom icons built on top of EuiIcon,
encapsulating logic related to mapping from data to the relative icon.
Apart from creating the new plugins, this also applies their usage to
the `infra` and `apm` plugins, while the Log Explorer flyout will
benefit from these working on
https://github.com/elastic/kibana/issues/170721.
## 🧪 How to test
### Infra
- Navigate to `Infrastructure -> Hosts`
- Verify the hosts table correctly renders the cloud provider icon for
each table entry.
### APM
- Navigate to `APM -> Services`.
- Verify each table entry correctly displays the related agent icon.
- Navigate to `APM -> Services`.
- Click on a service where t a cloud provider icon is expected to appear
next to the service name.
- Verify the icon is correctly displayed.
- Navigate to `APM -> Services -> Service Map`.
- Create a new group.
- Verify the agent icon is correctly displayed for each entry in the
preview list.
- Navigate to `APM -> Traces`.
- Verify each table entry correctly displays the related agent icon.
- Navigate to `APM -> Settings -> Agent Explorer`.
- Verify each table entry correctly displays the related agent icon.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Relates https://github.com/elastic/kibana/issues/104986
Hide Remote Elasticsearch output in serverless from Create/Edit output
flyout.
Should we also add validation to prevent creating it in API?
Verified locally by starting kibana in serverless mode:
<img width="751" alt="image"
src="061514f3-25fe-4e52-ad85-194cc612bea7">
### 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
Bug: https://github.com/elastic/kibana/issues/171167
The [previous
implementation](https://github.com/elastic/kibana/pull/170127) solved a
different bug using a new `shouldShowLegendAction` property. This
approach had a limitation on the Security Dashboards page since the
Security app has no control over the properties passed to the
visualization components when they are rendered through portable
Dashboards.
This PR fixes the problem by checking if any of the registered actions
is a "filter" action `type` in the visualizations. If customized filter
actions are found, the default filter actions hardcoded in the
visualizations code are not added, preventing duplication of filter
actions.
The specific action `type` used for the check is the
`FILTER_CELL_ACTION_TYPE = 'cellAction-filter'` constant exported by the
`@kbn/cell-actions` package.
This new approach uses a property stored in the registered actions
themselves, so we don't need to pass any extra property to the
visualization components, it works transparently. So the
`shouldShowLegendAction` property has also been cleaned.
## Demos
Timeline using `showTopN` visualization:
491c08e8-0740-4c9e-9cb7-81267b9ba040
Alerts page using `Counts` table visualization and `showTopN`
visualization
683eec6c-382e-4ae9-9400-c1022922e488
Portable Dashboard visualizations:
50f09a65-488d-41f2-a5b8-3882d9c80678
Security actions are "compatible" only inside the Security app, in the
Lens app the default filter actions are displayed:
<img width="1682" alt="lens-actions-screenshot"
src="1e7ce929-129d-45a9-ba71-8d28e3726454">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/169924
Related SDH: https://github.com/elastic/sdh-apm/issues/1080 (_internal_)
The APM data view is automatically created when opening the APM UI app
via a request to `POST /internal/apm/data_view/static`. This creates a
data view which is made available to all spaces. The problem with this
approach is that users can change index settings (apm index patterns)
per space, which means that there should be a data view per space as
well.
This PR ensures that a data view is created per space and that any links
to the data view uses the spaace specific dataview
---------
Co-authored-by: Caue Marcondes <caue.marcondes@elastic.co>
Co-authored-by: Cauê Marcondes <55978943+cauemarcondes@users.noreply.github.com>
