## Summary
### Part 1
- Resolves https://github.com/elastic/kibana/issues/164287
- Closes https://github.com/elastic/kibana/issues/146339
- Previously separate PR https://github.com/elastic/kibana/pull/164187
Changes:
- ~~swaps checkbox and row selection~~
- removes vertical borders
- adds rows highlight
- increases cell padding
- adds row stripes
- updates header background
- removes grey background from field name and makes it bolder (part of
https://github.com/elastic/kibana/issues/164634)
- updates Surrounding Documents side paddings
### Part 2
- Resolves https://github.com/elastic/kibana/issues/164661
- Previously separate PR https://github.com/elastic/kibana/pull/165687
Changes:
- removes background from panels, tabs and sidebar
- updates "Add a field" button style
- removes shadow from field list items
- makes field search compact
### Part 3
- Resolves https://github.com/elastic/kibana/issues/164662
Changes:
- wraps "Add a field" button in its own container with a top border
- ~~adds a drag handle to sidebar items~~
- ~~adds new Show/Hide buttons to toggle sidebar~~ moves sidebar toggle
button from discover plugin to unified field list
- reduces spaces between sidebar items from 4px to 2px
- reduces padding on Single Document page
- removes border above grid tabs
<img width="600" alt="Screenshot 2023-09-07 at 14 39 48"
src="976db247-fd70-4c9b-8634-552ece45b522">
Please note that "auto" row height is in a separate PR which is also
ready for review https://github.com/elastic/kibana/pull/164218
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
`data.search` uses
[poll_search](https://github.com/elastic/kibana/blob/main/src/plugins/data/common/search/poll_search.ts)
to fetch data. `poll_search` checks for `isErrorResponse` and throws
when`isErrorResponse` is true. **Note** `searchSource.search` uses
`data.search` to perform searches.
```javascript
return from(search()).pipe(
expand(() => {
const elapsedTime = Date.now() - startTime;
return timer(getPollInterval(elapsedTime)).pipe(switchMap(search));
}),
tap((response) => {
if (isErrorResponse(response)) {
throw response ? new Error('Received partial response') : new AbortError();
}
}),
takeWhile<Response>(isPartialResponse, true),
takeUntil<Response>(aborted$)
);
```
Subscribers to `data.search` and `searchSource.search` do not need to
check for `isErrorResponse` in `next`. `poll_search` has already thrown
then the response is `isErrorResponse` so these checks are dead code
blocks that are never executed.
This PR removes these dead code blocks. Breaking this change out of
https://github.com/elastic/kibana/pull/164506 so that it can be reviewed
in isolated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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
close https://github.com/elastic/kibana/issues/161545
close https://github.com/elastic/kibana/issues/153257
This PR makes `SavedObjectFinder` component backward compatible. It is
achieved by going through content- management layer, more technical
details
[here](https://docs.google.com/document/d/1ssYmqSEUPrsuCR4iz8DohkEWekoYrm2yL4QR_fVxXLg/edit)
### Testing
`SavedObjectFinder` is this component that allows to pick a saved object
(supports: `search` `index-pattern` `map` `visualization` `lens`
`event-annotation-group`:
It is used in the following places:
- Dashboard
- Add panel
- Replace panel
- Discover - Open Search
- Visualization - Select search as a source for new viz
- Graph - select source
- Cases - markdown editor add lens
- ML (3 places)
- Canvas - select embeddable panel
- Transform
- Lens > select event annotation
### Risks / Follow up
The `SavedObjectFinder` should stay mostly the same, the only notable
functional change is that now `SavedObjectFinder` doesn't support
`includeFields` which allowed partial saved object returns, this was
done to make the call backward-compatible without making the system even
more complicated as otherwise we'll need a way to abstract
`includeFields` from so attributes and allow to run migrations on it
before making a search. follow up issue to bring it back
https://github.com/elastic/kibana/issues/163043
The risk with that is that some client that have a lot of large objects
might run into performance issues when using `SavedObjectFinder`. This
can be mitigated by changing listing limit in advanced setting from
default 1000 to something lower
## 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.
closes https://github.com/elastic/kibana/issues/158561
## 📝 Summary
This PR adds a new customization point to allow for prepending custom
filter controls to the search bar.
At the moment we are only showing a default namespace filter, once this
is ready we will then check how to provide curated filters per
integration.
## ✅ Testing
1. Make sure to have some documents to different data sets with
different namespace, you can use [this
document](https://www.elastic.co/guide/en/elasticsearch/reference/current/set-up-a-data-stream.html)
as an example
2. Navigate to Discover with the log-explorer profile, `/p/log-explorer`
3. Validate that the new filter control is there
4. Filter using this new control and make sure documents are filtered
out
## 🎥 Demo
6828f62f-dd09-42bd-930c-dd7eaf94958b
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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
