## Summary
As part of #154888, we need to stop making direct requests to the index
`.kibana`, and use the SO Clients instead.
This PR changes the utility `getSavedObjectsCount` to use aggregations
in the SO client.
### 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
### 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)
I'm pointing to `main` because it's an improvement we needed anyway.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fields mapped as `constant_keyword` can cause issues when used in the
alerts as data mapping where multiple types of sources are combined into
one index. These fields were previously excluded from the ECS field
mapping used by alerts as data. We included them because we wanted to
use ECS as closely as possible but it is causing downstream issues so
we'll continue excluding them until we decide we need them at some point
in the future.
## To verify:
1. Start ES & Kibana
2. Inspect the `.alerts-ecs-mappings` component template mapping and
verify there are no fields with type `constant_keyword`
## Summary
Exports the list of valid Kibana timezones from the Core UI package, so
that it can be used in the snooze scheduler UI.
Previously we were using the same moment.tz list, but didn't have the
compatibility filter from Core UI. This will ensure the list of valid
timezones is synced up everywhere we need to show them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Update the versioned router based on current Elastic API spec.
Laundry list of changes:
1. Public versions must be specified as `^[0-9]{4}-[0-9]{2}-[0-9]{2}$`
e.g. 2023-12-12
2. For unsupported versions we respond with `400`
3. For incorrectly formatted versions we must respond with `400` and an
appropriate error message
4. Server must add the `Elastic-Api-Version` header to responses that
hit a versioned API
5. On serverless, a request WITHOUT a version header must default to
LATEST (TODO in follow up)
a. For Kibana, on prem must default to OLDEST
## Future work
Some way to toggle the handler resolution strategy from `oldest` to
`newest`. This could be Kibana config.
### 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
- Updates the logic of `ensureDeepObject` to remove unnecessary
properties when expanding the object
- We had three versions of this helper, centralized it within `@kbn/std`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> ⚠️ Synthetic failures are not related to any EUI changes and are
likely already failing on main. Please ignore the failing CI status when
reviewing.
## [`77.0.0`](https://github.com/elastic/eui/tree/v77.0.0)
**Bug fixes**
- Fixed named `EuiBadge` colors to reflect custom theme overrides
([#6659](https://github.com/elastic/eui/pull/6659))
- Fixed user-defined SCSS variables failing to override variables
defined in Amsterdam typography overrides.
([#6665](https://github.com/elastic/eui/pull/6665))
- Fixed bold `EuiCode` tokens to actually be bold
([#6666](https://github.com/elastic/eui/pull/6666))
**Breaking changes**
- Success- and accent-colored `EuiBadge`s and `EuiButton`s have had
their fill colors tinted slightly on light mode to be more readable
([#6659](https://github.com/elastic/eui/pull/6659))
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
This PR fixes the 3rd party external plugin development workflow by
introducing a dev step for plugins that allows for development usages of
those with Kibana.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR implements the Event Stream service for Content Management.
For high-level overview see:
- [Event Stream technical
summary](https://docs.google.com/document/d/1nyMhb0p4gNV43OVF6cLJkxhMf2V4V1BIjPsnACxe_t0/edit#heading=h.typ7x7sxmeye)
(a bit old, but still good as general overview read)
Implementation details in this PR:
- This PR introduces the `EventStreamService` high-level class, which is
the public interface to the Event Stream, holds any necessary state, and
follows plugin life-cycle methods.
- On a lower level the actual event storage is defined in the
`EventStreamClient` interface.
- There are two `EventStreamClient` implementations:
- `EsEventStreamClient` is the production implementation, which stores
events to Elasticsearch.
- `MemoryEventStreamClient` is used for testing and could be used for
demo purposes.
- The same test suite `testEventStreamClient` is reused for
`EsEventStreamClient` and `MemoryEventStreamClient`, which should help
with verifying that both implements work correctly and the same. For
`EsEventStreamClient` it is executed as Kibana integration test, but for
`MemoryEventStreamClient` it is executed as a Jest test.
- In `EventStreamService` events are buffered for 250ms or up to 100
events before they are flushed to the storage.
- Events are stored in the `.kibana-event-stream` data stream.
- The data stream and index template are create during plugin
initialization "start" life-cycle, similar to how it is done in the
Event Log and in the Reporting index.
- The mappings define a `meta` field, which is currently unused, but
will allow to add more fields in the future without needing to change
the schema of the data stream.
- The mappings define a transaction ID `txId` field, which can be used
to correlate multiple related events together or to store the
transaction ID.
- Events are written to Elasticsearch using the `_bulk` request API.
### 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: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
## Summary
Setting `xpack.alerting.enableFrameworkAlerts` to true by default. This
causes alerts-as-data resource installation to be handled by the
alerting plugin and not the rule registry. We're keeping the feature
flag in case we run into issues but eventually we'll clean up the code
to remove the feature flag and clean up the rule registry code that
relies on the feature flag. Changing this default setting early will
allow us to identify issues before the 8.8 FF where we can revert if
needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Related to #148911
This PR updates the guided onboarding landing page to filter solutions
based on user selected use case in cloud discovery questions. The value
will be passed as querystring parameter `?cloudDiscoveryUseCase=[value]`
from Cloud UI.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Now that we merged https://github.com/elastic/kibana/pull/153543, this
PR exposes the versioned router for teams to start using. The versioned
router will be available on `IRouter` under a new `versioned` property.
Primary benefit of this approach is that plugin developers will not need
to do anything other than "get" the `versioned` property to get a
versioned router.
Drawback is that this precludes us from passing in additional
configuration, like a version, to scope the versioned router instance.
For that we would need some kind of `createVersionedRouter({ version:
... })`. At this point it is not clear this is necessary, we could
revisit this decision based on actual usage. Plugin developers could
also do something like:
```ts
// common const
const MY_API_VERSION: ApiVersion = '1';
// in routes
import {MY_API_VERSION} from '../from/common';
router.versioned.get({ path: ... })
.addVersion({ version: MY_API_VERSION });
```
In this way they could get many of the same benefits of a version-scoped
version router, with the drawback that they need to pass this in for
every route.
### TODO
- [x] Add an integration test for the versioned router
### Future work
* We still need to consider revisiting some of the router design to
better support internal cases like adding support for registering a
handler for a version range and adding a default version to continue
supporting on-prem where introducing versions will be a breaking change
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/150309
Follow-up of https://github.com/elastic/kibana/pull/152219
Implement the second part of the zero-downtime migration algorithm: the
document conversion.
### Schema
because a schema is worth a thousand words:
<img width="650" alt="Screenshot 2023-03-22 at 08 33 44"
src="https://user-images.githubusercontent.com/1532934/226832339-d74d8349-9969-4c51-a5fe-f77558f17b67.png">
### TODO / notepad
- ~check that all types have model versions in INIT~ will do later when
we'll start have real types using MVs
- [x] Optimize to skip document migration when creating new index
- [x] documentsUpdateInit: extract remaining logic to utilities
- [x] outdatedDocumentsSearchRead: cleanup corrupted doc logic
- [x] outdatedDocumentsSearchTransform: cleanup corrupted doc logic
- [x] tests for /zdt/actions/wait_for_delay.ts ?
- ~support for coreMigrationVersion~ added as a follow-up in the parent
issue
- [x] init -> equal -> check if aliasActions is empty
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Updates comments for `removeReferencesTo` (SO Repository) and
`authorizeRemoveReferences` (SO Security Extension) methods with remarks
regarding the intended use and authorization.
Currently the only use case for `removeReferencesTo` is the delete
method of the tags client. If the authorization check is changed to
authorize an update for each referencing object, lingering references in
objects which the user is not authorized to update may be left behind
when a tag is deleted. We will leave the current implementation in place
until a decision about if & how to manage referential integrity occurs.
This PR documents the current intended use case for `removeReferencesTo`
as: "to provide clean up of any references to an object which is being
deleted (e.g. deleting a tag)."
See issue #135259 and discussion
[here](https://github.com/elastic/kibana/issues/135259#issuecomment-1482515139),
for background.
## Summary
Implements the designs from
https://github.com/elastic/kibana/pull/151596
* Move `packages/versioning/*` into `packages/core/http` to follow
existing structure more closely
* Implements the first iteration of the versioned router as a
wrapper/layer around the existing router
* Adds some integration tests
* Future work needed! Once we have a the versioned spec we should
implement it in this wrapper layer
* Validation is a little bit tricky because of when the
`CoreKibanaResponse` object is instantiated, the approach taken here is
to replace body, params, query on the route-level's request object
Closes https://github.com/elastic/kibana/issues/149286
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Migrates the transaction latency chart and the transaction group
statistics table to use service overview metrics/rollups when
appropriate.
Part of https://github.com/elastic/kibana/issues/152693 and
https://github.com/elastic/kibana/issues/146683 (the work is split up to
prevent a huge PR).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Søren Louv-Jansen <sorenlouv@gmail.com>
Closes https://github.com/elastic/kibana/issues/151702
## Summary
This PR migrates drag and drop logic from Lens plugin to a new package
so we can reuse it on Discover page later. At this point there should be
no visual changes. If you notice something, please comment on the PR.
- [x] Migrate drag&drop code to its own package `@kbn/dom-drag-drop`
- [x] Clean up i18n strings
- [x] Clean up styles
- [x] Adjust tests
- [x] Make telemetry optional
- [x] Configurable `data-test-subj`
Please test by using your mouse and also by using keyword shortcuts.
# Next steps
- Redesign for field list item (smaller button, a separate handle icon,
pill styles)
- Redesign for draggable buttons in the Lens layer panels (smaller
buttons)
-
[Figma](https://www.figma.com/file/SvpfCqaZPb2iAYnPtd0Gnr/KUI-Library?node-id=674%3A198901&t=OnQH2EQ4fdBjsRLp-0)
- https://github.com/elastic/kibana/issues/151703
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
