## 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>
Resolves https://github.com/elastic/kibana/issues/159392
## Summary
This PR hides the feature visibility section on the space management
screen and disables adding `disabledFeatures` when creating or updating
spaces using the REST API or spaces client on serverless.
## Screenshot
## Testing
1. Start Kibana in serverless mode: `yarn start --serverless`
2. Edit default space and observe that the feature visibility section is
not rendered
3. Quit Kibana and restart using classic mode: `yarn start`
4. Edit default space and observe that the feature visibility section is
rendered correctly
5. Other considerations:
- Disabling feature visibility in the classic offering should throw an
error (`xpack.spaces.allowFeatureVisibility: false`)
- Enabling feature visibility on serverless should throw an error
(`xpack.spaces.allowFeatureVisibility: true`)
## 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
### NOTE: This is a draft PR to MVP the new rule combination
(Threshold). More PRs to follow up
It fixes https://github.com/elastic/kibana/issues/158260 by providing
the _new_ **Threshold rule**
It fixes https://github.com/elastic/kibana/issues/159326
<img width="586" alt="Screenshot 2023-05-30 at 17 55 32"
src="0e485266-d93f-442e-81f4-77aa673ed497">
## ✅ Done
- [x] Clone the Metric threshold and update the imports
- [x] The rule is listed in the rule creation flyout with its params and
preview charts
- [x] Working Rule registry
- [x] Working Rule executor
- [x] Working feature id in the rule registry
- [x] Working alerts table and alert summary
- [x] Use DataView instead of the Metrics indices under settings
- [x] Update the i18n keys
- [x] Fix/Update failing checks/tests. Green CI ✅
- [x] Hide it behind a feature flag
`xpack.observability.unsafe.thresholdRule.enabled`
## 🏗️ To be done (could be irrelevant, or create a separate issue for
it):
- [ ] <del> Remove the `metrics` word </del>
- [ ] <del> Update file and variable names to match the new rule
context.</del>
- [ ] <del> Rearrange files, constants, and exports </del>
## 🎯 DoD
Having the rule working like the Metric threshold one and seeing its
related alerts.
---------
Closes https://github.com/elastic/kibana/issues/155371
## Summary
PR adds Serverless Onboarding flow using Custom Integration. This would
also lay the foundation for us to complete get rid of Home Tutorial App
and move the remaining `onPrem` and `cloud` tutorials which are
currently still loaded using Home Tutorial App.
1. Adds new Custom Integration for Serverless Onboarding (Toggling Home
AApp Tutorial Integration)
2. Since we are migrating away from the Home App Tutorials, lot of
existing code has been duplicated and refactored for the custom
implementation. Home App Tutorial would require the Server to register
all the steps and the client to only register a custom component which
then would be loaded by Home App Tutorial component. We don't need to
follow this approach any more. All the UX logic has now been moved to
the Public folder with only Custom Integration done on the
`server/plugin.ts`.
3. As we are not sure how the solutions will be informed about being
running on Serverless or not, I have introduced a new variable in
`serverless.oblt.yml` file called `xpack.apm.serverlessOnboarding:
true`. With this the development has been done. This can be changed to
actual logic once we know more.
4. A new configuration `xpack.apm.managedServiceUrl` for accessing
Managed Service URL is also being added by Control Plane team as part of
https://elasticco.atlassian.net/browse/CP-2403. Hence this PR expects
this property to be present for Serverless.
5. Unit tests to toggle between `secret_token` and `api_key` depending
on availability has been added. No API Tests were added as no new API
created. Cypress Tests cannot be added due to Serverless
## Need help reviewing the PR ?
1. `config/serverless.oblt.yml` - Adds the new flag which would enable
this flow
2. `x-pack/plugins/apm/common/tutorial/tutorials.ts` - Defines the
configuration required to register the APM's Tutorial Custom Integration
3. `x-pack/plugins/apm/public/components/app/tutorials/commands` - This
directory contains all the agent specific data required to load the
TABLE with settings required for configuring APM MIS.
4. `x-pack/plugins/apm/public/components/app/tutorials/instructions` -
This folder contains all the individual agent specific instructions in
the format used by
[EuiSteps](https://eui.elastic.co/#/navigation/steps#complex-steps)
5. `x-pack/plugins/apm/public/components/routing` - Here we register our
custom route
6. Changes on the server side a quite small and they only register the
custom integration.
7.
`x-pack/plugins/apm/public/components/app/tutorials/serverless_instructions.tsx`
- This file currently defines all the logic for registering Serverless
instructions. We will soon have similar files for `onPrem` and `cloud`
instructions
### Risk Matrix
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| The flow depends on presence of a flag in `kibana.yml` file. | Low |
High | By default this flow will be disabled and would fallback to
traditional onboarding in absence of the flag. |
### Demo
d60f0610-1fea-4540-86f5-2d72ab97f640
### Updated Demo with Create API Button inside the table
e84d8d6c-a048-4638-9b63-45080feca90b
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves#159028Resolves#159047
## Summary
Hide create spaces button when limit is reached.
## Screenshot
## Testing
1. Set the maximum number of allowed spaces to 1
```yml
xpack.spaces.maxSpaces: 1
```
2. Verify that the create spaces button is hidden and that a callout is
displayed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/154307
### Test
* Start kibana with `yarn start --serverless=es`
* set the following yaml configuration values
```
input_control_vis.readOnly: true
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes#157042
After the implementation of
https://github.com/elastic/kibana/pull/156837, we are now able to limit
the `logs.app_target` configuration to be accepted only in a serverless
environment, otherwise, it'll not be accepted.
Since we still need to use a default fallback value for the logs UI app,
the fallback will be applied internally when looking for this config, to
keep the original behaviour unchanged.
## 🧪 Testing
### Serverless environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
serverless-oblt`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` it redirects to discover.
### Normal environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
start`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` the log stream is rendered
correctly.
### Limited to serverless env
To verify that the configuration is only accepted under a serverless
context, set into your kibana.yml or `kibana.dev.yml` the configuration
```yml
xpack.infra.logs.app_target: discover
```
and verify that it triggers a validation error when running Kibana.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
- 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>
part of https://github.com/elastic/kibana/issues/154307
PR adds ability to put TSVB into read only mode - preventing TSVB
visualizations from being created and edited.
To test:
* start kibana with `yarn start --serverless=es`
* add `vis_type_timeseries.readOnly: true` to kibana.yml
Visualization public plugin changes:
* Removes `hideTypes` from VisualizationSetup contract. Used by Maps
plugin to set "hidden" to true for tile_map and region_map visualization
types. In 8.0, tile_map and region_map visualization type registration
moved into maps plugin so `hideTypes` no longer needed.
* Renamed vis type definition `hidden` to `disableCreate`.
* Added `disableEdit` to vis type definition.
* Hide edit link in dashboard panel options when `disableEdit` is true
* Does not display links and edit action in listing table when
`disableEdit` is true
Visualization server plugin changes:
* Add `readOnlyVisType` registry to set up contract
* Update visualization savedObject.management.getInAppUrl to return
undefined when vis type has been registered as readOnly.
* Prevents "readOnly "visualization types from being displayed in global
search results
* Prevents "readOnly "visualization types from having links in saved
object management listing table.
Timeseries server plugin changes:
* Add `readOnly` yaml configuration
* Expose `readOnly` yaml configuration to public
* When `readOnly` is true, call
VisualizationsServerSetup.registerReadOnlyVisType to mark vis type as
read only
Timeseries public plugin changes:
* Set disableCreate and disableEdit to true when `readOnly` is true
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Partially addresses https://github.com/elastic/kibana/issues/157756
## Summary
This PR makes the UI of the following Security apps disable-able for
serverless:
- Users
- Roles
- Role Mappings
**How to test:**
1. Start Elasticsearch with `yarn es snapshot` and Kibana with yarn
`serverless-{mode}` where `{mode}` can be `es`, `security`, or `oblt`.
2. Verify that the Users app is not accessible and its path
(`management/security/users`) leads to the Stack Management landing
page.
3. Verify that the Roles app is not accessible and its path
(`management/security/roles`) leads to the Stack Management landing
page.
4. Verify that the Role Mappings app is not accessible and its path
(`management/security/role_mappings`) leads to the Stack Management
landing page.
Test the Security apps in regular (non-serverless) mode:
1. Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
start`.
2. Verify that Users, Roles, and Role Mappings apps work as expected.
## Summary
Resolves https://github.com/elastic/kibana/issues/136856
- Add async keyword where it should have been.
- Split archive into kbn and es archives...
instigated by Pierre's comment:
https://github.com/elastic/kibana/issues/136856#issuecomment-1253609280
- Note: Had to use both archive types as
one archive is "hidden", and cannot be accessed via the kbn client.
- Unload via Pierre's "new" clean method.
- Add shell fn to print out server's currently loaded so's, with user
and pass hardcoded for local dev.
Fixes https://github.com/elastic/kibana/issues/155409https://github.com/elastic/kibana/pull/152516 incorrectly attempted to
resolve https://github.com/elastic/kibana/issues/151221.
https://github.com/elastic/kibana/pull/152516 updated shouldFetch$ to
only check searchSessionId to determine if re-fetching is required. This
logic did not work when custom time ranges are applied to panels since
custom time ranges do not require new search session id yet the time
range changed.
This PR reverts shouldFetch$ logic of only checking searchSessionId to
determine if re-fetching is required.
Instead, this PR moves searchSessionId out of input and into dashboard
instance state. That way, `input` updates, such as query, do not trigger
additional `input` updates. The PR also updates seachSessionId logic
from async to sync so that dashboard can update seachSessionId on input
changes prior to child embeddables updating to parent input changes.
This avoids the double fetch and allows children to only have a single
input update on query state change.
There was a functional test, panel_time_range, that should have caught
the regression but that test had a bug in it. The assertion that the
custom time range was applied looked like `expect(await
testSubjects.exists('emptyPlaceholder'))` which will never fail the test
because the last part of the expect is missing. Instead, the statements
should be `expect(await
testSubjects.exists('emptyPlaceholder')).to.be(true)`. These updates to
the functional test would have caught the regression (I verified this by
making these changes on main and running the test. They do indeed fail).
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: nreese <reese.nathan@elastic.co>
Closes#154733
Creates a new plugin for logs onboarding with wizard to organize steps
into discrete views.
#### TODO:
- [x] rename plugin to observability_onboarding
- [x] configure: UI and server plugin
- [x] enable/disable new plugin
- [x] remove the link to it from Observability nav
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Yngrid Coello <yngrid.coello@elastic.co>
Co-authored-by: Yngrid Coello <yngrdyn@gmail.com>
## 📓 Summary
Closes#153890
The implementation creates a new LogsApp service where we should keep
any logic concerned with what `target_app` parameter is configured and
the actions related to a specific configuration. I thought it could be a
good approach to avoid drilling down the global config till we need it
and keep it cleaner by injecting only the service with predefined
actions.
In this first case, we create a redirect to discover using its locator,
and the exposed method can be used anywhere across the app for
triggering the redirect.
## 🧪 Testing
### Normal behaviour
When Kibana is used as always, we want to keep the current behaviour and
the user will stay on the Logs UI pages.
- Launch the Kibana dev environment with `yarn start`
- Navigate to Logs UI
- Verify the navigation works normally and that no redirect to Discover
occurs
### Serverless behaviour
When Kibana is used in serverless mode, we want to redirect any user
landing to Logs UI to the Discover page, configuring the same data view
or creating an ad-hoc one starting from the index pattern
- Launch the Kibana dev environment with `yarn serverless-oblt`
- Navigate to Logs UI
- Verify to be redirected to Discover and a temporary data view is
created from the current index pattern
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes: https://github.com/elastic/kibana/issues/151935
This PR allows the mime types and max file size for the files
functionality within cases to be configured through the kibana.yml. We
set the defaults maxSize to be 100 mb and if it is not set by the user
we also restrict images to be 10 mb. If the `maxSize` is set by the user
we use it for all mime types including images (or whatever the user has
specified in `allowedMimeTypes`).
The file service changes are just mocks to help with testing some of the
configuration options.
New fields
```
{
files: {
allowedMimeTypes: string[]
maxSize: positive number (minimum 0) <-- exposed to the browser
}
}
```
## Release Notes
Cases added two configuration options to allow users to control which
files mime types are allowed to be attached to cases and the approved
max size of a file being upload.
`xpack.cases.files.allowedMimeTypes` - An array of strings representing
the allowed mime types to be attached to a case.
`xpack.cases.files.maxSize` - A number representing the file size limit
for files being attached to a case (in bytes).
## Summary
This PR removes the
`xpack.observability.unsafe.alertDetails.apm.enabled` feature flag to
enable the Alert Detail page for the APM Latency Threshold Rule. I've
also removed the`alertDetailsAppSection` options along with the
`alertDetailsUrl` action context variable for the remaining APM rules
since the APM Alert Detail page should only be available for the APM
Latency Threshold rule.
I also changed`isAlertDetailsEnabledPerApp()` method to allow the
`apm.transaction_duration` rule type to work but not `apm.error_rate`,
`apm.transaction_error_rate`, or `apm.anomaly` rule types. This change
was necessary because the granularity of the feature flag was set to the
solution level and didn't allow to set the flag per rule type.
### Testing
To test this PR you will need to have some APM data in your cluster.
1. Create an APM Latency Threshold Rule with a low threshold so it will
trigger
2. Create an APM Error Count Rule with a low threshold so it will
trigger
3. Click on the "Action Menu" (the ellipses) in the alert (in the Alert
Table) for the latency threshold alert
4. Click on the "View alert details" menu item for the latency threshold
alert
5. Verify it takes you to the new "alert details" page for APM
6. Repeat steps 3 & 4 for the error count alert BUT it should open the
"alert flyout" instead.
---------
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Introduces new config properties related to running `enterprise_search`
plugin without the `ent-search` service running. All three default to
`true` and retain the current behavior when they are set to `true`.
`canDeployEntSearch` - Setting to false will result in not showing the
Setup Guide for content pages when `config.host` is not set. Essentially
ungating indices, engines etc. pages.
`hasConnectors` - setting to `false` will result in hiding the connector
ingestion method when creating a new index.
`hasDefaultIngestPipeline` - setting to `false` will result in hiding
the index Pipelines and Content Settings page, until we can migrate
management of default ingest pipeline to the ES module
`hasNativeConnectors` - setting to `false` will result in hiding the
native connector ingestion method when creating a new index.
`hasWebCrawler` - setting to `false` will result in hiding the web
crawler ingestion method when creating a new index.
`hasNativeConnectors` & `hasWebCrawler` are intended to be temporary and
can be removed once we are sure the connectors service and web crawler
will be available in serverless.
## Summary
In-app chat should only be enabled in Cloud if a trial is still active.
https://github.com/elastic/kibana/pull/143002 added metadata including
`trial_end_date`. This PR:
- adds a config key to `cloud_integrations` for a `trialBuffer`, in
days, which defaults to ~~`30`~~ `60`.
- adds logic to not display chat if the trial end date + buffer exceeds
the current date.
- adds logic to not add a server route if the trial end date + buffer
exceeds the current date.
## Testing Locally
Add the following config to `kibana.dev.yml`:
```
xpack.cloud.id: "some-id"
xpack.cloud.trial_end_date: "2023-02-21T00:00:00.000Z"
xpack.cloud_integrations.chat.enabled: true
xpack.cloud_integrations.chat.chatURL: "https://elasticcloud-production-chat-us-east-1.s3.amazonaws.com/drift-iframe.html"
xpack.cloud_integrations.chat.chatIdentitySecret: "some-secret"
```
And start Kibana. You can optionally change the default of `30` days by
adding `xpack.cloud_integrations.chat.trialBuffer`.
## Storybook
Run `yarn storybook cloud_chat`.
## Testing in Cloud
Set the same config keys as above on a Cloud deployment.
## 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>
## Summary
Closes#150577
if there are too many agent policies in a system, we were creating too
big a runtime query for elastic and the query would be rejected.
This PR adds a limit, if the user has more than 750 agent policies then
agents will not be marked as inactive anymore. If the user reaches the
limit then a warning badge is displayed (the text underlined has also
been added):
<img width="968" alt="Screenshot 2023-02-13 at 20 14 31"
src="https://user-images.githubusercontent.com/3315046/218565456-f5758e4b-74f6-4e7c-9b49-22f0fd6f9102.png">
Integration test added.
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>
