## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### 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.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/190379
## Summary
This PR switches the example grid layout app to render embeddables as
panels rather than the simplified mock panel we were using previously.
In doing so, I had to add the ability for custom panels to add a custom
drag handle via the `renderPanelContents` callback - this required
adding a `setDragHandles` callback to the `ReactEmbeddableRenderer` that
could be passed down to the `PresentationPanel` component.
https://github.com/user-attachments/assets/9e2c68f9-34af-4360-a978-9113701a5ea2
#### New scroll behaviour
In https://github.com/elastic/kibana/pull/201867, I introduced a small
"ease" to the auto-scroll effect that happens when you drag a panel to
the top or bottom of the window. However, in that PR, I was using the
`smooth` scrolling behaviour, which unfortunately became **very**
jittery once I switched to embeddables rather than simple panels
(specifically in Chrome - it worked fine in Firefox).
The only way to prevent this jittery scroll was to switch to the default
scroll behaviour, but this lead to a very **abrupt** stop when the
scrollbar reached the top and/or bottom of the page - so, to give the
same "gentle" stop that the `smooth` scroll had, I decided to recreate
this effect by adding a slow down "ease" when close to the top or bottom
of the page:
https://github.com/user-attachments/assets/cb7bf03f-4a9e-4446-be4f-8f54c0bc88ac
This effect is accomplished via the parabola formula `y = a(x-h)2 + k`
and can be roughly visualized with the following, which shows that the
"speed up" ease happens at a much slower pace than the "slow down" ease:

#### Notes about parent changes
As I investigated improving the efficiency of the grid layout with
embeddables, one of the main things I noticed was that the grid panel
was **always** remounted when moving a panel from one collapsible
section to another. This lead me (and @ThomThomson) down a rabbit hole
of React-reparenting, and we explored a few different options to see if
we could change the parent of a component **without** having it remount.
In summary, after various experiments and a whole bunch of research, we
determined that, due to the reconciliation of the React tree, this is
unfortunately impossible. So our priorities will instead have to move to
making the remount of `ReactEmbeddableRenderer` **as efficient as
possible** via caching, since the remount is inevitable.
### Checklist
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
There are no risks to this PR, since the most significant work is
contained in the `examples` plugin. Some changes were made to the
presentation panel to allow for custom drag handles, but this isn't
actually used in Dashboard - so for now, this code is only called in the
example plugin, as well.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/201627
This is a short term fix for serverless and 8.x branches (long term fix
is an architectural change that will only be merged into 9.0 and 8.18
branches).
Fix prevents users from reseting a panel edited via embeddable transfer
service. This prevents panel from getting into an invalid state.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/180059
PR removes legacy embeddable factory support from Canvas and Dashboard
`Add from library` flyout
PR also does the following clean-ups
1) Renames folder, files, and component from `add_panel_flyout` to
`add_from_library_flyout`. When component was originally created,
dashboard `Add panel` button did not exist, and `Add from library`
button was called `Add panel`. Now that dashboard contains `Add panel`
and `Add from library` buttons, the old naming convention is super
confusing and not longer lines up with the current UI.
2) moves registry to `add_from_library` folder so that the registry is
in closer proximity to its usage.
2) Renames `registerReactEmbeddableSavedObject` to
`registerAddFromLibraryType` because
`registerReactEmbeddableSavedObject` does not clearly specifying what
the registry enables.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This is a follow up to EUI's Emotion conversion of
**EuiFormControlLayout/Delimited** (see
https://github.com/elastic/kibana/pull/190752,
https://github.com/elastic/eui/pull/7954, and
https://github.com/elastic/eui/pull/7957).
> [!note]
> Please manually QA your team's affected form control(s) to confirm
they still look and behave as expected and are non-broken. The EUI team
is not familiar enough with each plugin's setups to pull down and QA
this PR ourselves.
While QA testing the upgrade, I noticed a few incorrect usages of
**EuiFormControlLayout** but wanted to wait until after the upgrade to
push out fixes (to prevent delaying the PR further). In general, here is
EUI's [recommended usage of the
component](https://eui.elastic.co/#/forms/form-controls#form-control-layout):
- Where possible, **simply don't use it**. Almost all form controls are
**already** automatically wrapped in any EuiFormControlLayout by
default, and should accept a large majority of the props that the layout
accepts.
- If you **must** use it, set the `controlOnly` prop on the child
input/control to avoid buggy styling (e.g. duplicate borders).
- If you can't do either of the above for any reason (e.g. missing prop
support), reach out to the EUI team to ask for your UX as a feature
request!
### Checklist
Delete any items that are not applicable to this PR.
- [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))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
Consolidate to only exposing `DashboardApi` by removing
`DashboardExternallyAccessibleApi` and
`DashboardPluginInternalFunctions` types.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Extend embeddable examples with a state management example. PR also
refactors embeddable examples to use side nav instead of tabs.
<img width="800" alt="Screenshot 2024-09-11 at 8 38 28 AM"
src="https://github.com/user-attachments/assets/ac46600f-2c45-4f9e-b4f8-a5c03f4eef2f">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
PR adds PresentationContainer to embeddable examples. This example shows
developers how to create a dashboard like experience with embeddable
registry and PresentationContainer interfaces
### Test instructions
1. start kibana with `yarn start --run-examples`
2. install web logs sample data
3. navigate to `http://localhost:5601/app/embeddablesApp`
4. Select `PresentationContainer example` tab
### Presentation container example
Example starts with empty display and users can add embeddables
<img width="800" alt="Screenshot 2024-09-05 at 1 58 55 PM"
src="https://github.com/user-attachments/assets/406651ca-e611-4a3e-8b2d-4207eb5011b1">
Editing time range, adding or removing panels, or changing panel state
by adding custom time ranges will show unsaved changes and allow user to
reset changes or save changes
<img width="800" alt="Screenshot 2024-09-05 at 1 59 51 PM"
src="https://github.com/user-attachments/assets/cd84e39c-6de0-4ac6-832f-7d8e3682610b">
After adding an embeddable, user can use panel actions to remove the
embeddable
<img width="800" alt="Screenshot 2024-09-05 at 2 00 50 PM"
src="https://github.com/user-attachments/assets/63a2515c-f378-419f-b2f5-db71712fdffc">
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
## Summary

At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Update i18n tools after the main packages upgrade. This upgrade makes
use of formatJS tooling instead of fully implementing the parsers
ourselves. It also changes our custom AST parsing from babel to the
typescript compiler.
- [x] i18n exrtract
- [x] i18n check
- [x] i18n integrate
- [x] add test cases for formatjs runner
- [x] Make sure all CLI flags are handled properly
- [x] Update tooling readme
Closes https://github.com/elastic/kibana/issues/180616
Closes https://github.com/elastic/kibana/issues/187703
### Note to reviewers
Teams outside operations and core are probably requested to review
because the `i18n_check` fixed malformed i18n messages in your plugins.
Please check and approve :elasticheart:
## Summary
Closes https://github.com/elastic/kibana/issues/144418
This PR introduces changes to the dashboard add panel selection
functionality, so that panel selection would now happen from within a
flyout, and as such panels are now grouped together logically.
With this implementation any panel that is intended to show up within
this new flyout is required to have either been registered leveraging
the ui action trigger `ADD_PANEL_TRIGGER` and have it's `grouping` value
defined or belong to a subset of visualization types (`PROMOTED`,
`TOOLS`, and `LEGACY`) that would automatically get grouped.
It's worth pointing out that because we can't control the order at which
UI actions gets registered, we won't always get the the panel groups in
the same order, for this specific reason ~a new optional property
(`placementPriority`) has been added in~ the property `order` is now
leveraged such that it allows a user registering a UI action define a
relative weight for where they'd like their group to show up. All
registered actions would be rendered in descending order considering all
`order` defined, in the case where no order is defined `0` is assumed
for the group. In addition an action which is registered without a
group, would automatically get assigned into a default group titled
"Other".
The search implemented within the add panel is rudimentary, checking if
the group titles and group item titles contain the input character; when
a group title is matched the entire group is remains highlighted, in the
case that the group isn't matched and it's just the group item, only
said item is highlighted within it's group.
## Visuals
#### Default view
<img width="2560" alt="Screenshot 2024-06-10 at 17 44 17"
src="90aadf82-684a-4263-aecd-2843c3eff3c1">
#### Search match view
<img width="2560" alt="Screenshot 2024-06-10 at 17 45 11"
src="5a766f29-a3b7-40e3-b1f7-8b423073cd87">
##### P.S.
This changes also includes changes to the display of certain panels;
- ML group has a new title i.e. *Machine Learning and Analytics*
- In serverless, the observability panels (SLO*) only shows as a
selection choice in the observability project type.
### 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)
<!--
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
-->
- [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))
- [x] 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: Catherine Liu <catherine.liu@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/183766
### test instructions
1. start kibana with `yarn start --run-examples`
2. install sample web logs data set
3. create new canvas work pad
4. Click "Add element" -> "Filter" -> "Dropdown select"
5. Select "data" tab and configure filter to pull from logs sample data
and `machine.os.keyword` field.
6. Select "display" tab and "Value column" and "Filter column" to
`machine.os.keyword`.
7. Click "Add element" -> "Filter" -> "Time filter"
9. Click "Select type" -> "Search example"
10. Click panel context menu -> "Settings" and turn off custom time
range
11. Click "Expression editor" button in lower right corner to open the
expression editor for the map and prefix the expression with `kibana |
selectFilter | embeddable`
<img width="500" alt="Screenshot 2024-05-17 at 11 50 42 AM"
src="453096d5-c254-4f43-a09c-386586aa05a1">
12. Interact with drop down filter and time range filter. Verify Search
react embeddable updates as expected
Paired with @ThomThomson to expand Embeddable documentation with
"Guiding principles" and "Best practices"
PR also moves overview to src/plugins/embeddables/README.md. Then, this
markdown is displayed in the embeddable example application as well.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
Part of #182585
## Summary
Puts the `registerDashboardPanelPlacementSetting` function on the
Dashboard start contract.
Rather than importing the module directly, consumers will need to
include `dashboard` in their plugin's start dependencies.
Fixes#182113
## Summary
Adds a registry for plugins to specify the width, height, and placement
strategy for their embeddables.
To test this:
1. Run `yarn start --run-examples`
2. Load the Kibana sample data logs dataset
3. Start editing the [Logs] Web Traffic dashboard
4. In the "Add panel" dropdown, select the "Field list" subitem under
the "Embeddable examples" group
This also adds some additional documentation to the "Embeddables"
Developer examples.
Removes per-panel versioning and makes a few changes to further lock down types to make the new embeddable system more consistent and less error-prone.
PR adds "Register new embeddable type" section to Embeddable tutorial
<img width="600" alt="Screenshot 2024-04-25 at 12 25 59 PM"
src="075c534b-0b1b-4600-a057-d601d09da5d1">
PR also groups example embeddables to make them easier to find
<img width="600" alt="Screenshot 2024-04-25 at 12 26 12 PM"
src="82d55fca-bbe8-4b63-a80e-dd052307d7e5">
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
PR does the following
1. removes legacy example embeddables
2. Replaces FilterDebugger legacy embeddable with react embeddable
3. Moves FilterDebugger react embeddable to portable_dashboards_example
since that is where its used
4. Fixes DashboardContainer.addNewPanel to return ApiType for react
embeddables.
### test instructions
1. start kibana `yarn start --run-examples`
2. Open kibana menu and click "Developer examples"
3. Use developer examples search bar to find "Portable Dashboards"
example and click on the card
4. Verify first example that shows control filters works
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Changes
1. adds `hidePanelChrome` parameter to `ReactEmbeddableRenderer`. When
true, embeddable is rendered without `PresentationPanel` wrapper
2. Removes `embeddable-explorer` plugin
3. Moves Embeddable developer example into embeddable_examples plugin
4. Creates new examples that demonstrate how to use
`ReactEmbeddableRenderer`
<img width="600" alt="Screenshot 2024-04-23 at 5 19 18 PM"
src="5167a2a4-1968-42e6-92f7-4577c9cda3c6">
Follow-up work to narrow scope of this PR
1. add key concepts to embeddable overview
2. add "Register new embeddable type" tab that details how to create a
new embeddable and shows how you can add embeddable examples to
dashboard
3. group embeddable examples into a single item in "Add panel" menu - to
show best practices of how to keep menu clean
4. remove class based example embeddables
### Test instructions
1. start kibana with `yarn start --run-examples`
5. Open kibana menu and click "Developer examples"
6. Click "Embeddables" card and run examples
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/179838
1. define `PublishesSearchSource` interface
2. define `PublishesReload` interface
3. Add optional `timeslice$` to `PublishesTimeRange` interface
4. Update `DashboardContainer` to implement `PublishesSearchSource`,
`PublishesReload`, and `PublishesTimeRange` interfaces
5. `onFetchContextChanged` utility method created to consolidate fetch
context logic into a single re-usable component.
### Test instructions
1. Start kibana with `yarn start --run-examples`
2. Install sample web logs data set
3. create new dashboard, add `Unified search example` panel
4. Change time range, filters, search and verify panel fetches count for
narrowed data range
5. add timeslider control and advance timeslider, verify panel fetches
count for timeslice
6. Click reload, verify panel reloads count
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/179548
## Summary
This PR makes it so that React embeddables will now work in Canvas. It
does so by doing two main things:
1. It ensures that the `ReactEmbeddableRenderer` is used in Canvas when
an embeddable exists in the React embeddable registry - if it does not
exist, it continues to use the legacy embeddable factory's `render`
method.
Since Canvas auto-applies all changes and doesn't have save
functionality like Dashboard does, we must keep track of changes **as
they happen** and update the expression to match the new Embeddable
input - therefore, I had to add a `onAnyStateChange` callback to the
`ReactEmbeddableRenderer` as a backdoor for Canvas. As a bonus to this,
embeddables that **previously** didn't respect inline editing (such as
the Image embeddable) will start to work once they are converted!
3. It adds a new trigger (`ADD_CANVAS_ELEMENT_TRIGGER`) specifically for
registering an embeddable to the **Canvas** add panel menu. This trigger
can be attached to the **same action** that the Dashboard
`ADD_PANEL_TRIGGER` is attached to - this makes it super simple to add
React embeddables to Canvas:
```typescript
uiActions.registerAction<EmbeddableApiContext>({
id: ADD_EMBEDDABLE_ACTION_ID,
isCompatible: async ({ embeddable }) => { ... },
execute: async ({ embeddable }) => { ... },
getDisplayName: () => { ... },
});
// register this action to the Dashboard add panel menu:
uiActions.attachAction('ADD_PANEL_TRIGGER', ADD_EMBEDDABLE_ACTION_ID);
// register this action to the Canvas add panel menu:
uiActions.attachAction('ADD_CANVAS_ELEMENT_TRIGGER',
ADD_EMBEDDABLE_ACTION_ID);
```
As a small cleanup, I also replaced some inline embeddable expressions
with `embeddableInputToExpression` - this is because I was originally
missing `| render` at the end of my expression, and I didn't catch it
because the expressions I was comparing it to were all declared inline.
This should help keep things more consistent.
### How to Test
I attached the `ADD_EUI_MARKDOWN_ACTION_ID` action to the new
`ADD_CANVAS_ELEMENT_TRIGGER`, so the new EUI Markdown React embeddable
should show up in the Canvas add panel menu. Ensure that this React
embeddable can be added to a workpad, and make sure it responds to edits
as expected:
d9062949-9c61-4c9e-8a8e-08042753eab6
### 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
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### 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>
Closes [178630](https://github.com/elastic/kibana/issues/178630)
To run examples, start kibana with `yarn start --run-examples`
PR adds "Unified search example" to Dashboard "Add panel" menu
<img width="400" alt="Screenshot 2024-03-13 at 9 33 22 PM"
src="d1edb4f5-ac1e-49bd-ad03-f624af74fff1">
Embeddable displays count with unified search context from dashboard.
Changing unified search and global time picker will cause search to
update
<img width="400" alt="Screenshot 2024-03-13 at 9 34 09 PM"
src="675b2c7d-9fc0-4173-aa67-354483593c09">
Embeddable also allows for setting custom time range on the panel
<img width="418" alt="Screenshot 2024-03-13 at 9 34 52 PM"
src="a79ea546-c4ce-4af5-8bb3-7be9cac7c02c">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds the ability for the Dashboard to provide references for its React Embeddable children to inject, and adds the ability for the React Embeddable children to provide extracted references back to the Dashboard.
Changes the versioning scheme used by Dashboard Panels and by value Embeddables, and introduces a new clientside system that can migrate Embeddable Inputs to their latest versions.
## Summary
These examples are outdated and don't show recent embeddable best
practices. They also use client-side saved object client and block
making `SavedObjectFinder` backward compatible
https://github.com/elastic/kibana/pull/162904 as the `foobar` saved
objects need to be added to content management. We decided that it is
better to clean them up, as fixing them is not a small effort and it is
not worth it on this point as a large embeddable refactor is coming.