Resolves https://github.com/elastic/kibana/issues/159598
## Summary
This PR modifies the `test` subaction of the Generative AI connector to
accept a `stream` parameter (default: `false`) that allows for a
streaming response.
The Generative AI connector is basically a pass-through to the Open
AI/Azure OpenAI APIs, where the `stream` parameter is passed in via the
body of the request. This means that with the existing connector, users
could specify `stream: true` in the body which would lead to unexpected
results when the action is unprepared to return streaming results. This
PR sanitizes the body that is passed in the `run` subaction to prevent
the `stream` parameter from being set to `true` and explicitly sets the
`stream` parameter for the `test` subaction.
In order to test the streaming response, I created an example plugin
that prompts users to create a Generative AI connector if one does not
exist and then executes actions using the connector with `stream` set to
`true`. This borrows liberally from @dgieselaar's existing work from
https://github.com/elastic/kibana/pull/158678441694cb-0154-4450-bd93-3907c4a9995c
## To Verify
1. Navigate to https://localhost:5601/app/GenAiStreamingResponseExample
2. Set up a Generative AI connector
3. Open the network console. Enter a prompt and click `Stream Response`
4. You should see the chat response return streaming results.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/157203
Closes https://github.com/elastic/kibana/issues/158051
Closes https://github.com/elastic/kibana/issues/158049
With the addition of Per User Dark Mode, components can no longer rely
on `uiSettings` as the source of truth for theme.
CodeEditor fields used to call `uiSettings` to determine if Dark Mode
was enabled, which had been provided in each callers Kibana React
Context.
The new source of truth for theme is the `CoreStart >
ThemeServiceStart`.
Currently, not all callers of CodeEditor provide the `theme` service in
their Kibana Context in a similar way and some callers don't provide it
at all.
This PR updates CodeEditor to get theme values from the Kibana Context
using a new `useKibanaTheme` react hook.
It also attempts audit the callers of CodeEditor to see if their Kibana
Context contains the theme service at the top level (Where I could add
theme to a caller's Context without major changes, I did. Some cases
will require CodeOwner guidance).
The new `useKibanaTheme` react hook will throw a TypeError if theme
isn't found in the top level of the Kibana Context, this will help with
testing as the component will not render. I will remove this after
testing so as not to introduce breaking changes.
## Testing
Please review files for which you are CODEOWNER.
I've attempted to tag all usages of `CodeEditor`/`CodeEditorFIeld` with
a TODO comment with one of the following scenarios:
1) a note where theme was provided already/where I made changes to
provide it in the appropriate context
2) I've asked for CODEOWNER guidance
For scenario 1, please pull and test that CodeEditor locally:
1. Enable Dark Mode from Edit User Profiles by clicking on the Profile
Icon on the top right, and updating your profile.
2. Navigate to the CodeEditors in the plugins you own. If they render
and display in Dark Mode - add a green check to the table below - and
you're done!
3. If it is not rendering, please help me figure out where the theme
service should be provided in the context.
For scenario 2, we will need to figure out where to make changes so your
context is providing theme. Some of the more complex usages may need to
addressed in separate issues.
## Tracking
| Team | Plugin | Theme in Context ? | Verified Working |
| - | - | - | - |
| apm-ui | apm | APM Storybook broken | ? |
| kibana-presentation | presentation_util | Yes. | Yes |
| response-ops | trigger_actions_ui | Yes | Yes |
| response-ops | stack_alerts | Yes | Yes |
| kibana-security | security | Yes | Yes |
| security-defend-workflows | osquery | Yes | Yes |
| kibana-app-services | examples/expression_explorer | Yes | Yes |
| ml-ui | transform | Yes | Yes |
| ml-ui | ml | Yes | Yes |
| uptime | synthetics | Yes | Yes |
| kibana-gis | maps | Yes | Yes |
| kibana-gis | file_upload | Yes | Yes |
| platform-deployment-management | watcher | Yes | [AG] Yes |
| platform-deployment-management | snapshot_restore | Yes | [AG] Yes |
| platform-deployment-management | runtime_fields | Yes | [AG] Yes |
| platform-deployment-management | painless_lab | Yes | [AG] Yes |
| platform-deployment-management | ingest_pipelines | Yes | [AG] Yes |
| platform-deployment-management | index_management | Yes | [AG] Yes |
| platform-deployment-management | grokdebugger | Yes | [AG] Yes |
| platform-deployment-management | es_ui_shared | Yes | [AG] Yes |
| fleet | fleet | Yes | Yes |
| enterprise-search-frontend | enterprise_search | Yes | [AG] Yes |
| kibana-cloud-security-posture | cloud-security-posture | Yes | yes |
| sec-cloudnative-integrations | cloud_defend | Yes | Yes |
| kibana-visualizations/kibana-data-discovery | data | Yes | Yes |
| kibana-visualizations | examples/testing_embedded_lens | Yes | Yes |
| kibana-visualizations | vis_types | Yes | Yes |
| kibana-visualizations | vis_default_editor | Yes | Yes |
| kibana-visualizations | unified_search | Yes | Yes |
| kibana-visualizations | packages/kbn-text-based-editor | Yes | Yes |
| kibana-visualizatons | lens | Yes | Yes|
| kibana-core | saved_objects_management | Yes | Yes |
| kibana-presentation | inspector | Yes | Yes |
| kibana-presentation | canvas | Yes | Yes |
| kibana-data-discovery | discover | Yes | Yes |
| kibana-data-discovery | data_view_management | Yes | Yes |
| kibana-data-discovery | data_view_field_editor | Yes | Yes |
| appex-sharedux | advanced_settings | Yes | Yes |
| enterprise-search-frontend | serverless_search | Yes | [AG] Yes |
| - | - | - | - |
## Unit tests
Currently, many tests are failing since they are probably not providing
`theme` in the context. Once CODEOWNERs have weighed in on CodeEditors
usages that require discussion, I will update the accompanying tests.
## Release note
- Fixes theming of CodeEditors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alison Goryachev <alisonmllr20@gmail.com>
Co-authored-by: Dima Arnautov <dmitrii.arnautov@elastic.co>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Summary
The NativeRenderer component is currently used to mount another
component in a separate mounting point. As far as I recall, we
introduced <NativeRenderer/> to allow users to create visualizations in
non-React frameworks. The idea was that users could write their own Lens
visualizations or datasources code and integrate it with our system.
However, it seems that this concept hasn't gained traction and we don’t
have it prioritized. Even if users express interest in writing their
visualizations outside of React, it is still possible to do so with some
additional boilerplate code (which we could provide as an example
non-React visualization).
Pros:
1. Simplifies and shortens the code:
1.1. Testing and debugging become easier as we no longer need to check
separate React trees when integrating frame, data source, and
visualization components.
1.2. Components communicate using standard React patterns, making
maintenance and comprehension simpler.
1.3. Context providers no longer need to be passed to each separate
component since they are already within the context.
1.4. Easier propagation of events or any other form of inter-component
communication.
2. Greatly improves performance and facilitates maintenance:
2.1. Directly accessing context inside the DatasourcePanel eliminates
the need for context passing, resulting in better performance.
2.2. Removing the requirement for a separate React root also contributes
to improved performance.
3. The render method will be removed when we upgrade to React 18. While
we could replace it with the new createRoot method, it makes sense to
perform some cleanup ;)
Cons:
1. Setting up non-React visualization or data source code might become
slightly more complex.
Performance improvement for drag and drop action with these changes:
before:
<img width="1110" alt="Screenshot 2023-07-10 at 07 14 39"
src="45a1b09b-5189-46f5-af2b-7781fcf4e774">
after:
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="0e704da1-3220-4eb9-8fa0-cc3584a90090">
## Single render when dragging:
(the first image is 3 screenshots from 3 different react roots as they
have separate mounting point. The complete render time is ~380ms)
<img width="1117" alt="Screenshot 2023-07-10 at 07 16 24"
src="6d7f2d9f-a758-476e-8efb-38693ae90097">
After we have one common render tree. Because we don't have to pass
context down as a prop, we greatly reduced the number of components
rerendered. (I will be working on reducing the render time for workspace
panel as this seems to still be a bottleneck point)
<img width="732" alt="Screenshot 2023-07-10 at 14 52 41"
src="03ec97b3-8225-490e-8884-0fd4e69587e8">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes#160737
This PR adds support for title and description within the Embeddable
overrides realm.
While there also enables the support for overrides for the new TagCloud
visualization.
The playground example has been extended to test it for any type of
chart:
<img width="572" alt="Screenshot 2023-06-30 at 10 17 04"
src="8b069c2f-dd31-4aaa-9ded-0e33f34b4860">
### 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
- [ ] 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>
`IVectorSource` interface has many similar sounding methods that are
used for different purposes. These lead to confusion and an unclear API
* getFieldNames
* getFields
* getFieldByName
Although `getFieldNames` sounds similar to `getFields`, the 2 are used
for very different purposes.
* getFieldNames returns a string array that is used to trigger source
re-fetch
* getFields returns an array of fields to drive UI such as field
selection for data driven styling
`getFieldNames` overlaps 100% in functionality with `getSyncMeta` and is
not needed. Combining output of `getFieldNames` into `getSyncMeta`
simplifies the `IVectorSource` API and removes some confusion.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Why?
To simplify the process of migration to react-router@6.
https://github.com/remix-run/react-router/discussions/8753
What problems exactly it solves?
- In my previous PR I added `CompatRouter`
https://github.com/elastic/kibana/pull/159173, which caused changes in
~50 files and pinged 15 Teams. And this is just meant to be a temporary
change, so when we're done with the migration I would have to revert
these changes and engage everyone to review the PR again. And it is just
a single step in the migration strategy. So to make our lives easier I
think it would be better to have a common place where we do import our
router components because it will allow us to surface some extra logic
in single place instead of going through the whole source code again.
- `react-router@6` doesn't support a custom `Route` component, so that
means our custom `Route` component that we're using almost everywhere
today, will need to be replaced by a different solution. I have decided
to add `Routes` component, which will be responsible for rendering the
proper component (`react-router@6` renamed `Switch` to `Routes`, so I
have named this component to align with the dictionary of the new
router) and also is going to add the logic that today is done in `Route`
(moving logic to `Routes` will be done in the follow-up PR, here I just
wanted to focus on using the common router components to make the review
process easier)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/150364
Fixes: https://github.com/elastic/sdh-kibana/issues/3806
Fixes a common complaint and bug where we limit the number of tags that
are displayed in the tags dropdown to 50. We now paginate these results
with a max tag of 10,000 (50 per page). It's not a true pagination
because Elasticsearch doesn't support filtering and paginating on
aggregation buckets (bucket selector doesn't work on terms). Since tags
are not nested properties or references, they can only be reached
through terms aggregation.
But at least we don't return 10000 tags from the API.
## How to test:
1. By default we show 50 tags per page, to make testing easier, you may
go to `x-pack/plugins/alerting/server/rules_client/methods/get_tags.ts`
and set `DEFAULT_TAGS_PER_PAGE` to 10 or something
2. Create some rules
3. Create some tags (spread amongst the rules would be even better)
4. Open the tag filter
5. Should be able to search, paginate, and filter rules by the tags
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Relates to:** https://github.com/elastic/security-team/issues/5308
## Summary
This PR make improvements and simplifications to `RulesListNotifyBadge` component exported by `triggers_actions_ui` plugin spotted during [adoption](https://github.com/elastic/security-team/issues/5308) of this component in Security Solution.
## Details
The list of the changes
- Mixed controlled and uncontrolled state has been resolved in favour of controlled state. It means an external code is responsible to fetch and provide rule snooze settings to the component.
- Loading state management has been moved inside the component. The only way to to set the component in loading state it to provide `undefined` for `snoozeSettings` input prop.
- Popover's open/close state management has been moved inside the component. I haven't noticed any problems in tables (Stack Management Rules and Security Solution Rules) if there are multiple rules are shown with `RulesListNotifyBadge` rendered. In attempt to open another snooze popover a previous one closes automatically.
- `rule` input prop has been renamed to `snoozeSettings`.
- `isEditable` field has been moved to a separate `disabled` prop. `disabled` can accept a string which is considered as a disabled reason and displayed in a tooltip. It's quite helpful to display for example fetching errors.
- `onRuleChanged` handler can return a promise so internal loading state persists until this promise resolved.
### Checklist
- [ ] [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/))
- [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))
Resolves: #153755
This PR intends to make rule type param validation function required.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR:
- Moves the case bulk actions from the solutions to the alert table
- Refetch when using the case row actions & the case bulk actions.
- Renames the `kibana.alert.case_ids` label to `Cases`
- Unskip the `alerts_table.test.tsx` test file and skip the individual
flaky tests. I run the test file 60 times in the CI without any issues
(9efed89ee9)
- Renames the cases flyout and modal hook from `get*` to `use*`
Fixes: https://github.com/elastic/kibana/issues/151688
## Userflow
## Testing
### Alerts table
- The alerts table does not show the Cases column by default
- You can choose the case column from the fields modal. Type `Case` to
find the cases column
- The label of the column is `Cases`
- The label of the field in the fields modal is `Cases`
- You can bulk attach alerts to a new case
- You can bulk attach alerts to an existing case
- When bulk attaching alerts to a case the alerts table re-fetches the
data
- When attaching an alert to a case from the row actions the alerts
table re-fetches the data
### Case integrations outside the alerts table
- Ensure that you can attach your data to a case (existing and new)
### 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)
- [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#kibana-release-notes-process)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/153804
PR resolves issue by passing `SourceRequestMeta` to
`ITMSSource.getUrlTemplate`, giving `getUrlTemplate` the state needed to
update raster URL when required.
PR also resolves the following tech debt:
* rename `searchFilters` -> `requestMeta` to better reflect contents of
parameter.
* Map API's leak lots of implementation details. This PR took the time
to clean up one instance by moving `isGeoGridPrecisionAware` and
`getGeoGridPrecision` from `ISource` to `IESAggSource`
* moved `geogridPrecision` from `VectorSourceRequestMeta` into
`sourceMeta`.
* Removed `VectorJoinSourceRequestMeta` since its same as
`VectorSourceRequestMeta` now that `VectorSourceRequestMeta` does not
contain `geogridPrecision`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
👋 Hi all - the biggest breaking change of this PR is around two icon
type changes/renames.
1. ⚠️ **The `alert` icon is now named `warning`**
- <img width="103" alt=""
src="https://user-images.githubusercontent.com/549407/223561599-8913e88c-676f-47cd-aaed-81b64783bd81.png"
align="middle">
- This change should have been automatically converted on your behalf by
the EUI team, **but if for some reason** we missed making this
conversion in this PR and your icon(s) are now broken, please ping us or
let us know in this PR (or fix yourself after this PR merges).
- In some cases, teams were using this icon for error messages,
alongside the `danger` color. In those cases, we opinionatedly changed
those icon usages to the new `error` icon instead of using the old
alert/warning icon.
2. 🛑 **The `crossInACircleFilled` icon has been removed, and a new
`error` icon added**
- <img width="84" alt=""
src="https://user-images.githubusercontent.com/549407/223561892-4406bdf6-1a55-49ac-85ad-3a11eb7c090d.png"
align="middle">
- The conversion for this breaking change was not straightforward. This
was the path we used to determine what to change `crossInACircleFilled`
usages to:
- If the icon was associated with errors or error messages, we changed
it to the new `error` icon.
- If a "delete" action was associated with this icon, we changed it to
the `trash` icon instead.
- If a "clear" action was associated with this icon, we changed it to
just the `cross` icon, or in some cases `minusInCircleFilled` (if used
alongside `plusInCircleFilled`).
- Again, if we made a mistake during this conversion or missed your
plugin, please feel free to ping us.
## Summary
`eui@75.1.2` ⏩ `eui@76.0.2`
## [`76.0.2`](https://github.com/elastic/eui/tree/v76.0.2)
**Bug fixes**
- Added a legacy `alert` alias for the `warning` `EuiIcon` type
([#6640](https://github.com/elastic/eui/pull/6640))
## [`76.0.1`](https://github.com/elastic/eui/tree/v76.0.1)
**Bug fixes**
- Fixed broken icons on all `isInvalid` form controls
([#6629](https://github.com/elastic/eui/pull/6629))
## [`76.0.0`](https://github.com/elastic/eui/tree/v76.0.0)
- Added `pivot` glyph to `EuiIcon`
([#6605](https://github.com/elastic/eui/pull/6605))
- Added the `displayHeaderCellProps` API to `EuiDataGrid`'s columns,
which allows passing custom props directly to column header cells
([#6609](https://github.com/elastic/eui/pull/6609))
- Added the new `headerCellProps`/`footerCellProps` APIs to
`EuiDataGrid`'s control columns, which allows passing custom props
directly to control column header or footer cells
([#6609](https://github.com/elastic/eui/pull/6609))
- Added a new `footerCellRender` API to `EuiDataGrid`'s control columns,
which allows completely customizing control column rendering (previously
rendered an empty cell)
([#6609](https://github.com/elastic/eui/pull/6609))
- Updated the styling of nested ordered lists in `EuiText` to align with
GitHub's list style, which is a popular format used in Markdown or MDX
formatting ([#6615](https://github.com/elastic/eui/pull/6615))
- Added a margin-bottom property exclusively to the direct child `ul`
and `ol` elements of the `EuiText` component
([#6615](https://github.com/elastic/eui/pull/6615))
- Fix issue with badges appearing within an `EuiBadgeGroup`, where the
CSS rule to override the `margin-inline-start` was not being applied
correctly due to the order of appearance in the CSS rules
([#6618](https://github.com/elastic/eui/pull/6618))
**Bug fixes**
- Fixed `EuiDataGrid` footer control columns rendering with cell
expansion popovers when they should not have been
([#6609](https://github.com/elastic/eui/pull/6609))
- Fixed an `EuiSkipLink` bug where main content loading in
progressively/dynamically after the skip link rendered was not being
correctly focused ([#6613](https://github.com/elastic/eui/pull/6613))
**Breaking changes**
- Renamed `EuiIcon`'s `alert` to `warning`
([#6608](https://github.com/elastic/eui/pull/6608))
- Removed `EuiIcon`'s `crossInACircleFilled` in favor of `error`
([#6608](https://github.com/elastic/eui/pull/6608))
---------
Co-authored-by: Davey Holler <daveyholler@hey.com>
Co-authored-by: Constance Chen <constance.chen@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
## Summary
Resolves https://github.com/elastic/kibana/issues/137164.
This PR adds a new `revision` field (number) to Alerting Rules that
auto-increments when relevant content changes have been made via the
`Rules Client`. _Relevant content changes_ are defined as any content
change that the user may either want to be notified about, or have the
option to later revert to. This will include most all changes, except
the enabling/disabling of the rule, or updates to metadata fields like
`executionStatus` or `monitoring`. This `revision` field is not intended
to be user editable, and should be ignored if ever provided via the API.
See https://github.com/elastic/kibana/issues/136213 for additional
details. To be followed-up by
https://github.com/elastic/kibana/issues/137168, which will remove the
version bump logic from security solution.
## Details
### Migrations
Includes SO migration to default `revision` to `0` when upgrading a
cluster, or when importing `pre-8.8.0` rules via the SO Management UI.
For consistency, security rule import follows the same logic as SO
Management and will not reset the `revision` to `0` when overriding or
creating a new rule.
### Downstream Index Updates
* EventLog _has not_ been updated to include `revision` along with basic
rule fields currently being written. Should we?
* AAD Schema will be updated in
https://github.com/elastic/kibana/pull/151388 (as this one is getting
pretty big) to include `revision` so alerts written will include which
specific revision of the rule created the alert.
### Reference Fields
Any creation of or modification to `actions` will result in a revision
increment. More typical reference fields like `exception lists` on the
security side will only result in a revision increment when the list is
initially associated/deleted from the rule (as subsequent updates will
be done directly against the list).
### RuleClient Updates
The following methods within the RuleClient have been updated to support
incrementing revision when relevant field changes have been detected:
* `clone()` - resets to 0 currently (see open question)
* `update()` - increments `revision` so long a change has been made to
relevant fields (fields not in [ignore
list](https://github.com/elastic/kibana/pull/147398/files#diff-6736e143ede2dc06e825bddcdc23b4d088a6620805751db4eddc5900d586c4dfR69-R85))
* `bulkEdit()` - increments `revision` for relevant fields (all current
bulk edit fields minus api key/snooze/mute)
Mutation methods not updated to include revision log:
* `snooze()`
* `unsnooze()`
* `clearExpiredSnoozes()`
* `muteAll()`
* `unmuteAll()`
* `muteInstance()`
* `unmuteInstance()`
* `updateApiKey()` - increments revision as rule functionality could be
impacted
## Open questions:
- [X] Should `clone()` in RulesClient reset revision to 0 as if it's a
new rule, or keep the current value? (see
[comment](https://github.com/elastic/kibana/pull/147398/files#r1106484105))
- [X] What about snooze/un-snooze, and mute/unmute? Should we update
revision on these field changes as well? (see
[comment](https://github.com/elastic/kibana/pull/147398/files#r1106431966))
- Discussed with @XavierM and determined to not update on
snooze/mute/API key changes as this actions could be plentiful and don't
necessarily represent a version of the rule a user would want to revert
to, thus polluting the revision history.
- [ ] Should we write `revision` to EventLog?
---
### Checklist
Delete any items that are not applicable to this PR.
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] To work with docs team
- [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#kibana-release-notes-process)
Resolves: https://github.com/elastic/kibana/issues/145132.
In this PR, I'm adding a new function to the server-side rule type
definition called `viewInAppRelativeUrl`. This function returns a
relative path to view the rule in the proper application that will
provide more context. This relative path is used to build the `rule.url`
mustache variable for the actions (overriding the rule details page link
when defined) as well as a fallback for the UI's `View in App` button if
no navigation is registered on the front-end.
Follow up issues:
- https://github.com/elastic/kibana/issues/149608
- https://github.com/elastic/kibana/issues/151355
## ML to verify
1. Create an anomaly detection rule from the ML application
2. Go to stack management rule details page
3. Click "View in App"
4. Ensure it brings you to the ML app properly.
5. Repeat step 1 to 4 in a space that isn't the default
Note: ML won't take advantage of the new functionality yet, but we plan
to help in a follow up https://github.com/elastic/kibana/issues/149608
so that ML anomaly detection rules can provide a view in app URL within
the rule action messages.
## ResponseOps to verify
1. Set `server.publicBaseUrl` to the proper value in your kibana.yml
6. Modify the [index threshold rule
type](https://github.com/elastic/kibana/blob/main/x-pack/plugins/stack_alerts/server/rule_types/index_threshold/rule_type.ts#L108-L136)
to have a `getViewInAppRelativeUrl` function returning
`/app/management/insightsAndAlerting/triggersActionsConnectors/connectors`.
7. Create an index threshold rule that always fires. Make sure to add a
a server log action that contains the `{{rule.url}}` variable.
8. Pull the printed URL from the server logs and make sure it works and
brings you to the connectors page.
9. Navigate to the rule details page, click the "View in App" button and
ensure it also brings you to the connectors page.
10. Create a Kibana space.
11. Go into that created space and repeat step 3 to 5. Ensure the URL
and View in App keep you in the same space.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR removes all imports of Route from react-router-dom and
'@kbn/kibana-react-plugin/public' and instead imports Route from
@kbn/shared-ux-router.
### Context
Based on
https://github.com/elastic/kibana/issues/132629#issue-1243243678 This PR
executes steps 2 - 4:
> 2. To make the transition easier, we want to re-export other
react-router-dom exports alongside the modified' Route'.
> 3. Solutions should start using that Route component in place of the
one from react-router-dom. I.e. replace all occurrences of import { ...
} from 'react-router-dom' with import { ... } from
'@kbn/shared-ux-router'.
> 4. All manual calls to useExecutionContext are not needed anymore and
should be removed.
### Future PR
Looks like this might be getting worked on in:
https://github.com/elastic/kibana/pull/145863 (thanks!)
> Introduce an ESlint rule that ensures that react-router-dom is not
used directly in Kibana and that imports go through the new
@kbn/shared-ux-router package.
This is tangentially accomplished through
https://github.com/elastic/kibana/pull/150340 but only addresses using
Route through @kbn/kibana-react-plugin/public'
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiagoffcc@hotmail.com>
Fixes https://github.com/elastic/kibana/issues/149344
This PR migrates all plugins to packages automatically. It does this
using `node scripts/lint_packages` to automatically migrate
`kibana.json` files to `kibana.jsonc` files. By doing this automatically
we can simplify many build and testing procedures to only support
packages, and not both "packages" and "synthetic packages" (basically
pointers to plugins).
The majority of changes are in operations related code, so we'll be
having operations review this before marking it ready for review. The
vast majority of the code owners are simply pinged because we deleted
all `kibana.json` files and replaced them with `kibana.jsonc` files, so
we plan on leaving the PR ready-for-review for about 24 hours before
merging (after feature freeze), assuming we don't have any blockers
(especially from @elastic/kibana-core since there are a few core
specific changes, though the majority were handled in #149370).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
We wanted to avoid duplication of code so we created a more integrated
component with API to snooze rule. we also added the information about
snooze in the task runner so security folks can manage their legacy
actions in the execution rule, it will looks like that
```ts
import { isRuleSnoozed } from '@kbn/alerting-plugin/server';
if (actions.length && !isRuleSnoozed(options.rule)) {
...
}
```
One way to integrated this new component in a EuiBasictable:
```
{
id: 'ruleSnoozeNotify',
name: (
<EuiToolTip
data-test-subj="rulesTableCell-notifyTooltip"
content={i18n.COLUMN_NOTIFY_TOOLTIP}
>
<span>
{i18n.COLUMN_NOTIFY}
<EuiIcon size="s" color="subdued" type="questionInCircle" className="eui-alignTop" />
</span>
</EuiToolTip>
),
width: '14%',
'data-test-subj': 'rulesTableCell-rulesListNotify',
render: (rule: Rule) => {
return triggersActionsUi.getRulesListNotifyBadge({
rule: {
id: rule.id,
muteAll: rule.mute_all ?? false,
activeSnoozes: rule.active_snoozes,
isSnoozedUntil: rule.is_snoozed_until ? new Date(rule.is_snoozed_until) : null,
snoozeSchedule: rule?.snooze_schedule ?? [],
isEditable: hasCRUDPermissions,
},
isLoading: loadingRuleIds.includes(rule.id) || isLoading,
onRuleChanged: reFetchRules,
});
},
}
```
I think Security solution folks might want/need to create a new io-ts
schema for `snooze_schedule` something like that should work:
```ts
import { IsoDateString } from '@kbn/securitysolution-io-ts-types';
import * as t from 'io-ts';
const RRuleRecord = t.intersection([
t.type({
dtstart: IsoDateString,
tzid: t.string,
}),
t.partial({
freq: t.union([
t.literal(0),
t.literal(1),
t.literal(2),
t.literal(3),
t.literal(4),
t.literal(5),
t.literal(6),
]),
until: t.string,
count: t.number,
interval: t.number,
wkst: t.union([
t.literal('MO'),
t.literal('TU'),
t.literal('WE'),
t.literal('TH'),
t.literal('FR'),
t.literal('SA'),
t.literal('SU'),
]),
byweekday: t.array(t.union([t.string, t.number])),
bymonth: t.array(t.number),
bysetpos: t.array(t.number),
bymonthday: t.array(t.number),
byyearday: t.array(t.number),
byweekno: t.array(t.number),
byhour: t.array(t.number),
byminute: t.array(t.number),
bysecond: t.array(t.number),
}),
]);
export const RuleSnoozeSchedule = t.intersection([
t.type({
duration: t.number,
rRule: RRuleRecord,
}),
t.partial({
id: t.string,
skipRecurrences: t.array(t.string),
}),
]);
```
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/148760
Makes the rules setting link that opens up the flapping settings modal
shareable from the `triggers_action_ui` plugin (`getRulesSettingsLink`).
Also adds storybook entires for this component (`rulesSettingsLink`).
To view locally, run `yarn storybook triggers_actions_ui`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
This PR upgrades uuid into its latest version `9.0.0`.
The previous default used version `v4` was kept where it was previously
used and places using `v1` or `v5` are still using it.
In this latest version they removed the deep import feature and as we
are not using tree shaking it increased our bundles by a significant
size. As such, I've moved this dependency into the `ui-shared-deps-npm`
bundle.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
In this PR, I'm changing the return type of rule executors from `return
state;` to `return { state };`.
This change had to touch all rule type executors so they return `state`
as a key. In the future, the framework could accept more than `state` in
the object, like warnings as an example.
**Before:**
```
executor: async (...) {
const state = {...};
return state;
}
```
**After:**
```
executor: async (...) {
const state = {...};
return { state };
}
```
**Future:**
```
executor: async (...) {
return {
state: {...},
warnings: [...],
metrics: {...},
...
};
}
```
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Removes `UiComponent` and its usages.
- Fixes UI Actions TypeScript types.
### 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
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <dosantappdev@gmail.com>
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Add legends to custom map layers and convert wms_source to typescript
Co-authored-by: Sean Sullivan <ssullivan@spectric.com>
Co-authored-by: Nick Peihl <nickpeihl@gmail.com>
* memoize is selected observable
* added on upload start and upload end cbs
* listen for uploading state, also i18n for search field
* added uploading state
* updated the files example plugin
* rework the footer to include the compressed upload component
* prevent change page when uploading
* revert change to search field
* added pass through the on upload callback so that consumers can respond to upload events
* updated i18n
* export DoneNotification type from upload files state
* added test for uploading state
* added common page and page size schemas
* make sure the file$ does not collapse on error
* hide pagination if there are no files
* added a small test to check that pagination is hidden when there are no files
* do not error in send request method
* react with loading spinner to new page or retry requests
* do not fetch on every change? in files example app
* remove lazy from the file picker image
* absolute position the image tag to ensure that it is visible, this ensures the intersection observer will fire
* remove the "lazy" prop from the image component
* remove unnecessary if
* added comment and increase page size of file picker in files example plugin
* make the empty "hidden" image occupy the full container space
* added unscoped file client to the files components context
* wip: created some basic files and stories for new filepicker component
* fix some types after require filesclient to be passed in
* added file picker state and some basic tests
* added file picker context
* added missing file client value
* updated file picker stories
* expanded files context;
* remove the size observable and also added a test for file removal and adding of duplicates
* added error content component
* refactor upload component to not take files client as prop
* updated shared file compoennts context value
* added test for adding multiple files at once
* allow passing in string or array of strings
* added some i18n texts
* move the creation of a file kinds registry to a common location
* set file kinds only once
* a bunch of stuff: added title component, using grid, removed responsive on upload controls
* refactor layour components to own component using grid, added new i18n texts for empty state prompt
* minor copy tweak
* added basic story with some files
* added file grid and refactored picker to only exist in modal for now
* get the css grid algo that we want: auto-fill not auto-fit!
* override styling for content area of file
* split stories of files
* delete commented out code
* give the modal a fixed width
* fix upload file state, where we do not want a fixed width modal
* moved styles down to card, and combined margin removal rules
* optimize for filtering files, first pass just filter on names
* include xxl
* moved debounceTime to rxjs land, added test for filtering behaviour
* added story with more images
* big ol wip
* empty prompt when uploading a file
* added pagination
* fixed tests and added some comments
* address lint
* moved copy to i18n and updated size and color of empty error prompt
* remove use of css`
* remove non existant prop
* also reload files
* fileUpload -> files
* update logic for watching if selected
* disambiguate i18n ids
* use abort signal and call sendRequest from file$, filtering done server side now, update tests
* fix a few off by one errors and hook up the new system to the ui
* added test for in flight requests behaviour
* update the files example app
* fix minor card layout styling to make all cards the same size regardless of text or image conten
* added new file picker component
* make file cards a bit wider and text a bit smaller so that it wraps...
* fix issue of throwing abort error and prematurely setting request to completed...
* remove unused import
* replace filter i18n
* a bunch of cool changes
* added export for the file picker component
* updated example app to use multiple file upload
* added some comments and made images load eagerly in file picker for now...
* complete ux for examples
* only files that are "READY" should be in the file picker
* set loading to false if error
* install data-test-subj everywhere!
* added some react component tests
* remove unused import
* fix storybook case
* fix up where the files example plugin is listed, moved it to the developer examples area
* fix potential flashing of loader by debouncing
* do not create new observable on every render
* i18n
* have only filepicker ctx used in filepicker components
* refactor loadImageEagerly -> lazy
* useObservable instead of useEffect
* factor modal footer to own component and remove css util
* use the middle dot luke
* copy update in files example app
* added filter story
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* added blurhash dep
* send blurhash from client
* added blurhash to server side
* added blurhash to headers
* added hash to files headers part ii
* move custom header name to shared
* added server side test to make sure blurhash is being stored with the file
* move blurhash logic to common components logic
* wip: moving a lot of stuff around and breaking up image component to parts
* added logic for loading blurhash client-side using header values
* reorder some stuff, added http to files context for example
* added resize files test
* tweak sizes of the blurs
* removed custom blurhash header
* renamed util to blurhash
* fixed some loading states to not show alt text, updated stories to show blurhash and removed styling on container
* remove http from filescontext
* pass blurhash to image component
* improved usability of the component by passing in wrapper props and allowing consumers to set an image size the same way they can for EuiImage
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* removed all traces of blurhash field from file saved object
* create special file image metadata type
* rename blurhash files and return full image metadata
* refactor blurhash in upload state to image metadata factory
* finish refactor of blurhash file
* pass back the original image size to the metadata
* more refactoring and added some comments to the metadata type
* pass metadata type through to endpoint
* pass metadata type through on client side
* wip
* updated files example to pass through shape of metadata
* some final touches
* updated comment
* make default size original
* rename common -> util
* update import path after refactor
* update style overrides for the blurhash story
* MyImage -> Img
* fix type lints
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* added modal and removed hardcoded image upload
* remove unused var
* added shared imports file and hooked up modal component to example app
* use the Image component from files and update the title for the files modal
* set and show custom metadata
* fix content type not being passed through to upload or to picker component
* remove old commented out code
* first commit
* first commit
* get auth index and try field caps
* use esClient
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* wait for promise to finish
* logs for debugging
* format field capabilities
* add simplier browserFields mapper
* update response and remove width
* update response
* refactor
* types and refactor
* update api response
* fix column ids
* add columns toggle and reset
* sort visible columns id on toggle on
* merging info
* call api
* load info on browser field loaded
* remove logs
* add useColumns hook
* remove browser fields dependency
* update fn name
* update types
* update imported type package
* update mock object
* error message for no o11y alert indices
* add endpoint integration test
* activate commented tests
* add unit test
* comment uncommented tests
* fix tests
* review by Xavier
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* remove unnecessary api calls
* update types
* update param names + right type
* update types
* update id and index to be same type as rest
* update timelines id and index format
* add schema update on load
* add functional test
* fix tests
* reactivate skipped test
* update row action types to work with new api
* rollback basic fields as array update o11y render cell fn
* update cell render fn to handle strings too
* update column recovery on update
* recover previous deleted column stats
* add browser fields error handling
* add toast on error and avoid calling field api when in siem
* remove spread operator
* add toast mock
* update render cell cb when value is an object
* remove not needed prop
* fix browser field types
* fix reset fields action
* add missing hook dependency
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* fix browser field modal types
* update browser field types
* update render cell
* update export type
* fix default columns
* remove description column in browser field modal
* fix populate default fields on reset
* delete description field in triggers_actions_ui
* avoid to refetch the data because all the data is already there
* remove description tests
* insert new column in first pos + minor fixes
* update onToggleColumn callback to avoid innecesary calls
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Xavier Mouligneau <xavier.mouligneau@elastic.co>
* Update all usages of EuiPageTemplate to EuiPageTemplate_Deprecated
* EuiPageContent_Deprecated as EuiPageContent
* EuiPageContentBody_Deprecated as EuiPageContentBody
* EuiPageContentHeader_Deprecated as EuiPageContentHeader
* EuiPageContentHeaderSection_Deprecated as EuiPageContentHeaderSection
* EuiPageSideBar_Deprecated as EuiPageSideBar
* EuiPageContent__Deprecated to EuiPageContent_Deprecated
* Fix rogue semi-colons
* WIP: NoDataConfigPage & NoDataPage converted to new template
- `withSolutionNav` not yet handled
* WIP: KibanaPageTemplateInner converted to use new template
- Pushes existing `pageHeader` prompts onto created EuiPageTemplate.PageHeader
- Uses `isEmptyState` to push `pageHeader` props to EuiPageTemplate.EmptyPrompt instead (if `children` are not supplied)
* WIP: `withSolutionNav` now renders the sidebar content properly
- Collapsing isn’t working (minWidth isn’t updating)
* Fixing stickiness of sidebar
* [Security] Fixed SecuritySolutionTemplateWrapper’s usage
- Moved `bottomBar` to EuiPageTemplate.BottomBar (now contained in just the page contents)
- Change EuiPanel children wrapper with EuiPageTemplate.Section
* [O11y] Wrap `children` with EuiPageTemplate.Section
* Fix getting_started usage
* WIP: Fixing types
* Removing `template` pass through
* Set EUI to 63.0.0
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* More import fixes
* Sidebar component update
* Expand `KibanaPageTemplate` to all namespaced EUI counterparts
- Updated `docs/tutorials` mdx page
- Fixed SolutionNav prop types
* Updated the tutorial mdx page
* [Stack Management] Updated app layout to new template
- Some temporary props applied for BWC until all other pages can be converted
- Converted `API Keys` page’s layout (and especially prompt usags) to new paradigm
* Fix circular dep
* Fix new circular dependency
- copying and pasting types from KibanaPageTemplateProps, but ah well
* [Security Solution] Remove `template` prop - no longer a prop on Kibana/EuiPageTemplate
* [O11y] Allow customizing EuiPageTemplate.Section wrapper
- converts pageBodyProps
- fixes non-centered loading template
* [Enterprise Search] Update page templates
- fix layouts by auto-wrapping an EuiPageSection for padding, while adding a `customPageSections` prop for more custom sections/layouts
- re-center 404 errors
- update tests
* Update KibanaPageTemplate tests
* Update snapshots
* Fix FTR test with removed EUI classNames
* Fix FTR tests with changed kbn classNames
* Update failing dashboard snapshots
- drop shadow changed slightly in EUI
* Fix failing Security Cypress test
* [O11y] Fix Inventory page using deprecated CSS hooks
* [O11y][Uptime] Fix missing bottom bars
- Modifies ObservabilityPageTemplate to accept a `bottomBar` prop (a la the old EuiPageTemplate behavior)
NOTE: This opinionated page layout structure is starting to feel like it could be potentially limiting / have all the same pitfalls the previous EuiPageTemplate did. If so, consider something closer to the Enterprise Search page template conversion (`customPageSections`).
- Misc cleanup: Use `KibanaPageTemplate` over `EuiPageTemplate`
* [O11y] Fix route template typing
- Since theObservabilityPageTemplate is using the new Eui/KibanaPageTemplate, its child templates and types need to be updated accordingly
* Fix broken minWidth behavior
- was an EUI issue that required a patch release
+ update snapshots
* [Security Solution] Type fixes, restore empty state
- Fix empty state logic removed in a previous commit
- bogarts KibanaPageTemplate's `isEmptyState` prop instead of using `template="noData"`
- extend template wrappers to past ...rest to underlying Kibana/EuiPageTemplate
+ replace EuiPageTemplate with KibanaPageTemplate for consistency
* Fix failing synthetics selector
* Grab EUI v63.0.6
- for deprecation tags and section tag support
* Fix Kibana Overview plugin layout
- needs to use KibanaPageTemplate.Section to get padding back
- use `bottomBorder` prop over horizontal rules
- restore previous page color via panelled=false
* Convert Home plugin to new KibanaPageTemplate
- use KibanaPageTemplate.Section instead to preserve page width/paddings
- use `bottomBorder` instead of `EuiHorizontalRule`
- NOTE: This causes margins to decrease slightly from xxl to xl (largest padding available for EuiPageSection) - this can be restored by CSS overrides if desired
- update CSS to preserve previous looks, + convert to logical properties
* [O11y] Fix non-centered empty/loading states
* [O11y] Restore subdued background on various empty state prompts
* [O11y] Fix all instances of views that require a scrollable full-height child
+ restore comment for inventory view
* [O11y][ux] Fix broken sidebar
- The entire app was missing a wrapping EuiProvider, and as such breakpoint utils were not working, and the sidebar was missing
+ misc cleanup
- remove unnecessary fragment
- remove role="main" attr - now that EuiPageTemplate sets a `main` tag, they'll conflict
- add isEmptyState to center loading component
* [APM Cypress tests] harden flaky test
* [APM Cypress tests] Fix failing Cypress test, again
Co-authored-by: cchaos <caroline.horn@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
