Migrates deprecated EUI components for the response stream developer
example plugin. Adds a breadcrumb to the example to be able to navigate back to the overview page.
- Originally Kibana's `http` service did not support receiving streams,
that's why we used plain `fetch` for this. This has been fixed in
#158678, so this PR updates the streaming helpers to use Kibana's `http`
service from now on.
- The PR also breaks out the response stream code into its own package
and restructures it to separate client and server side code. This brings
down the `aiops` bundle size by `~300KB`! 🥳
- The approach to client side throttling/buffering was also revamped:
There was an issue doing the throttling inside the generator function,
it always waited for the timeout. The buffering is now removed from
`fetchStream`, instead `useThrottle` from `react-use` is used on the
reduced `data` in `useFetchStream`. Loading log rate analysis results
got a lot snappier with this update!
## Summary
Fix https://github.com/elastic/kibana/issues/161424
Migrate away from deprecated EUI components for Core-owned code.
Note: I only tested the production (and examples) pages properly, I
didn't make sure the test plugins where displayed correctly, as long as
the data structure was still here for the tests to pass.
### Screenshots
#### Status page
<img width="1388" alt="Screenshot 2023-07-10 at 17 14 24"
src="d15adffa-d4fb-4dab-ad91-691a4c103541">
#### AppNotFound page
<img width="1352" alt="Screenshot 2023-07-10 at 17 14 40"
src="77dcc958-db53-4ec8-9a7f-af4ea0804a96">
#### Generated plugin landing page
<img width="1906" alt="Screenshot 2023-07-10 at 17 15 44"
src="7a45d1a3-181d-44c5-a4a1-d3bdb2ba6ee9">
---------
Co-authored-by: Kibana Machine <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
When I created drag and drop for Lens, the API I went for was not the
most readable one. It was designed this way because I wanted to gain
some performance, but it was very hard to maintain the performance gain
with a lot of changes in the drag and drop area because all the pieces
of the code needed to memoized in a tricky way and it wasn't
communicated well.
In the end it works even without these tricks so I decided to simplify
it in this PR.
The main changes include:
1. Instead of multiple `useState` per parameter, we keep all the state
in reducer both for `ReorderProvider` and `RootDragDropProvider`. Thanks
to that we get multiple improvements:
2. The code in `DragDrop` component becomes more descriptive as we don't
run multiple state updates when user executes an action but one state
update describing what actually happens (eg. `dispatchDnd({type:
'selectDropTarget' ....})`. The internal logic of the update lives in
the reducer.
3. We don't have to pass `trackUiCounterEvents` as another prop to
`DragDrop` and run it wherever we need - instead we pass it as a
middleware to the context and run before dispatching (and it's very easy
to add more middlewares if we need extra integrations at some point!)
4. We also run a11y announcements as a middleware instead of inside
`DragDrop` component
5. The `ChildDragDropProvider` props look much cleaner:
before:
```
<ChildDragDropProvider
keyboardMode={keyboardModeState}
setKeyboardMode={setKeyboardModeState}
dragging={draggingState.dragging}
setA11yMessage={setA11yMessage}
setDragging={setDragging}
activeDropTarget={activeDropTargetState}
setActiveDropTarget={setActiveDropTarget}
registerDropTarget={registerDropTarget}
dropTargetsByOrder={dropTargetsByOrderState}
dataTestSubjPrefix={dataTestSubj}
onTrackUICounterEvent={onTrackUICounterEvent}
>
{children}
</ChildDragDropProvider>
```
after:
```
<ChildDragDropProvider value={[state, dispatch]}>{children}</ChildDragDropProvider>
```
6. Created custom hook `useDragDropContext` instead of using
`useContext(DragContext)` and making DragContext private. This way we
will avoid potential problems with using context outside of root.
7. Bonus thing - if we ever decide to move to redux, the structure is
there already
What I am still not happy with is that the tests are very
domain-dependant instead of user-driven - instead of checking the store
actions, I should check the interface from the user perspective. I will
try to work on it once I find some time between more important tasks
though.
closes https://github.com/elastic/kibana/issues/161428
PR also updates examples title. Instead of naming the embeddable used,
the title now reflects what the example demonstrates.
* "Hello world embeddable" -> "Render embeddable"
* "Todo embeddable" -> "Update embeddable state"
* "List container embeddable" -> "Groups of embeddables"
* "Dynamically adding children to a container" -> "Context menu"
There is a lot more that could be done to enhance these examples, but I
did not want to get more side tracked then I already did.
---------
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>
- Closes https://github.com/elastic/kibana/issues/149336
## Summary
This PR converts `unifiedFieldList` plugin into a new
`@kbn/unified-field-list` package.
Had to also move some deps:
- from `uiActions` plugin to the existing `@kbn/ui-actions-browser`
package
- from `data` plugin to a new `@kbn/data-service` package
Please test that Field Stats from the package are still working on your
pages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds versioning to the AIOps API.
Versions are added to the server side routes and to the client side
functions which call the routes.
Updates API tests to add the API version to the request headers.
The single API endpoint is already internal and now has been given the
version '1'.
**Internal APIs**
`/internal/aiops/explain_log_rate_spikes`
- Closes https://github.com/elastic/kibana/issues/147885
- Closes https://github.com/elastic/kibana/issues/157109
## Summary
**Before:**
Unified Field List plugin has internal routes (wrappers for client code)
which exist only to run api functional tests against them:
- `/api/unified_field_list/existing_fields/{dataViewId}`
- `/api/unified_field_list/field_stats`
Client code does not call these routes directly. So there is no reason
in keeping and versioning them.
**After:**
- Internal routes are removed
- A new "Unified Field List Examples" page was created
http://localhost:5601/app/unifiedFieldListExamples
- API functional tests (which used the routes) were converted to
functional tests against this new example page
- Created a new `unifiedFieldList` page object which is used now in
functional tests (methods are extracted from existing `discover` page
object).
**For testing:**
Steps:
1. Run Kibana with examples: `yarn start --run-examples`
2. Install sample data
3. And navigate to Developer Examples > Unified Field List Examples
page.
### 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>
## Summary
Fixes https://github.com/elastic/kibana/issues/149132
This PR adds a Kibana feature for the guided onboarding plugin for
better permissions handling. By default `kibana_admin` and `editor`
roles are granted access to guided onboarding. The role `viewer` on the
other hand doesn't have enough permissions to see or use guided
onboarding. For any roles that don't have the correct permissions,
guided onboarding is completely disabled, the same as it's disabled
on-prem.
When creating a new role, the feature "Setup guides" can be enabled or
disabled.
### How to test
1. Add `xpack.cloud.id: 'testID'` to `/config/kibana.dev.yml`
1. Start ES with `yarn es snapshot` and Kibana with `yarn start``
2. Login as elastic and create a test user with the role `viewer`
3. Clear everything from your browser's local storage
4. Login as the test user and check the following
- On the first visit, the "on-prem" welcome message is shown (not the
guided onboarding landing page)
- The url `/app/home#/getting_started` is unknown and redirects back to
the home page
- There is no button "Setup guides" in the header
- There is no link "Setup guides" in the help menu
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/143322
This PR adds an option to store dynamic parameters when a step is
completed to be used later for dynamically built URLs.
### How to test
1. Add `xpack.cloud.id: 'testID'` to your `/config/kibana.dev.yml` file
2. Start ES with `yarn es snapshot`
3. Start Kibana with `yarn start --run-examples`
4. Navigate to the guided onboarding example plugin
`http://localhost:5601/app/guidedOnboardingExample`
5. Start the test guide and when completing step 1 provide any value for
the paramter `indexName`
6. Continue the guide until step 4 and check that the correct value is
being used for the url of this step.
### 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
Part of https://github.com/elastic/kibana/issues/152224
Follow up to https://github.com/elastic/kibana/issues/153256
This PR onboards maps CM integration into the multi-type search
(`msearch`). It isn't actually used anywhere in the user-facing UI yet,
as first other types need to be migrated to CM.
This PR also adds an example app to test the `msearch` end-to-end.
Aligns the Portable Dashboard renderer and the Control Group renderer to a new API structure using `useImperativeHandle` rather than the overcomplicated and mostly unused wrapper provider system.
## Summary
This PR adds the option to provide, custom props when calling
`openAddDataControlFlyout`. For example, users of the API may want
different placeholder than default for any new options list that is
added.
Currently, in security solution, we need a custom placeholder for newly
added controls. Hence, this PR. Please let me know if this is not the
best way to do this.
https://user-images.githubusercontent.com/7485038/232775198-a111d711-ffba-4d26-8c70-c2af08008e05.mov
## Summary
Partially addresses https://github.com/elastic/kibana/issues/152224
[Tech Doc
(private)](https://docs.google.com/document/d/1ssYmqSEUPrsuCR4iz8DohkEWekoYrm2yL4QR_fVxXLg/edit#heading=h.6sj4n6bjcgp5)
Introduce `mSearch` - temporary cross-content type search layer for
content management backed by `savedObjects.find`
Until we have [a dedicated search layer in CM
services](https://docs.google.com/document/d/1mTa1xJIr8ttRnhkHcbdyLSpNJDL1FPJ3OyK4xnOsmnQ/edit),
we want to provide a temporary solution to replace client-side or naive
server proxy usages of `savedObjects.find()` across multiple types with
Content Management API to prepare these places for backward
compatibility compliance.
Later we plan to use the new API together with shared components that
work across multiple types like `SavedObjectFinder` or `TableListView`
The api would only work with content types that use saved objects as a
backend.
To opt-in a saved object backed content type to `mSearch` need to
provide `MSearchConfig` on `ContentStorage`:
```
export class MapsStorage implements ContentStorage<Map> {
// ...
mSearch: {
savedObjectType: 'maps',
toItemResult: (ctx: StorageContext, mapsSavedObject: SavedObject<MapsAttributes>) => toMap(ctx,mapsSavedObject), // transform, validate, version
additionalSearchFields: ['something-maps-specific'],
}
}
```
*Out of scope of this PR:*
- tags search (will follow up shortly)
- pagination (as described in [the doc]([Tech
Doc](https://docs.google.com/document/d/1ssYmqSEUPrsuCR4iz8DohkEWekoYrm2yL4QR_fVxXLg/edit#heading=h.6sj4n6bjcgp5))
server-side pagination is not needed for the first consumers, but will
follow up shortly)
- end-to-end / integration testing (don't want to introduce a dummy
saved object for testing this, instead plan to wait for maps CM onboard
and test using maps https://github.com/elastic/kibana/pull/153304)
- Documentation (will add into
https://github.com/elastic/kibana/pull/154453)
- Add rxjs and hook method
👋 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
Close https://github.com/elastic/kibana/issues/152002
In https://github.com/elastic/kibana/pull/151163 we introduced a simple
demo todo app run in a storybook with a custom client-side content
management client (no server-side cm registry usage).
This is a follow-up PR that re-uses the same demo todo app, but also
runs it in an example plugin with proper server-side content management
registry usage, so now we have a basic end-to-end demonstration of
content management capabilities. The demo app is covered by functional
tests, so now we also have basic end-to-end test coverage.
As this is the first kind of real-world end-to-end usage of the CM APIs,
I'd like to use this and
[previous](https://github.com/elastic/kibana/pull/151163) prs as a base
for the discussion and polishing current APIs. I'll leave a review with
comments where I think some API polishing is needed.
**Notable changes apart from the example plugin itself:**
1. Move `demo/` todo app and its stories introduced in
https://github.com/elastic/kibana/pull/151163 from
`src/plugins/content_management` to
`examples/content_management_examples`. This was mostly needed to not
export `demo/` code on the public plugin export to avoid increasing
bundle size.
2. Add needed exports to the plugin contract
3. Reshuffle `common/` to not import `@kbn/schema` client side
48aa41403b
4. Fix client-side RPC client to work with the latest server-side
changes (shouldn't break from now on because of the end-to-end test
coverage)
## Summary
Closes https://github.com/elastic/kibana/issues/151985
- ~~This PR introduces `maxUploadSize` file kind setting, which allows
to enforce upload size per file, instead of using one value for the
whole file kind~~.
- ~~I left the `maxSizeBytes` as-is for now, because it is actually used
in two places: (1) in the Files client; (2) in HTTP routes. So, I didn't
find an easy way to reuse it~~.
- Allows to configure max upload size per file.
- This required separation of `FileKind` interface between browser and
server. And correspondingly changes to the file kind registry.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds an "add" button that shows up to the right of the Control Group if
configured. Also adds a system for fetching settings from consumers, and
adds settings that can hide or show pieces of the Control editor flyout.
## Summary
Added the `meta` prop to the `FilePicker` component, also pass this down
to the `FileUpload` component so that files created via the picker can
have meta set.
Close https://github.com/elastic/kibana/issues/151375
## How to test
1. Start Kibana with examples `yarn start --run-examples`
2. Go to the "Developer examples" in the side-nav menu under analytics
3. Go to "Files example"
4. Upload a file via the "Select file" button, should present an empty
file picker if you have no files, otherwise use the little upload
component bottom left
5. Either select files or dismiss the modal
6. Inspect the uploaded file and see the `myCool: 'meta'` entry included
with other metadata
## Screenshot
A file uploaded via the `FilePicker` in the "Files example" plugin.
<img width="897" alt="Screenshot 2023-02-16 at 11 41 06"
src="https://user-images.githubusercontent.com/8155004/219342872-c39b5d81-7421-4187-bb1c-d6815d80a3dc.png">
### 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
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
Fixes https://github.com/elastic/kibana/issues/149691
Follow up to https://github.com/elastic/kibana/pull/149528
This PR adds 3 separate guide ID values `appSearch`, `websiteSearch` and
`databaseSearch` instead of previously used `search`. With that change,
each card for Search on the landing page has its own independent guide
that can be completed.
Example plugin for guided onboarding is also updated so that all 3
search guides can be managed there. Otherwise there should not be any
UI/UX changes.
Currently, all 3 ids are registered with the same config and that can be
easily updated by the team in the future.
#### Screenshot
<img width="485" alt="Screenshot 2023-01-31 at 18 24 12"
src="https://user-images.githubusercontent.com/6585477/215840343-f9a65be3-0568-40ca-b458-5de92bfe8aaf.png">
### 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>
This PR moves the test guide used for testing and dev work to the guided
onboarding package. It is now being registered when the guided
onboarding example plugin is being setup. For that a server side is
added to the example plugin.
Registering the test guide from the example plugin demonstrates how the
"register guide" function can be used for production guides. The test
config needs to be in the `kbn-guided-onboarding` package because
example plugins have some problems importing files from other plugins.
That way the test config is available to the example plugin and to the
guided onboarding plugin for unit and functional tests.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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>
## 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>
Part of https://github.com/elastic/kibana/issues/145428
PR does the following:
* Removes ControlsCallout
* Cleans up ControlGroupContainer API to avoid leaking Dashboard
implementation details
* Removes getCreateControlButton method
* Removes getCreateTimeSliderControlButton
* Removes getToolbarButtons
* Adds openAddDataControlFlyout
* Add Edit and save example
<img width="600" alt="Screen Shot 2022-12-21 at 9 29 21 AM"
src="https://user-images.githubusercontent.com/373691/208928858-94984880-3fdb-45f4-bb2a-a086bfc440d0.png">
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
