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>
## Summary
Part of https://github.com/elastic/kibana/issues/150312
(next steps depend on https://github.com/elastic/kibana/pull/153117)
**This PR does two things:**
- introduce the concept of version persistence schema
- adapt the document migrator to support downward migrations for
documents of an higher version.
In the follow-up, we will then update the calls from the SOR to the
document migrator to allow downward conversions when we're using the ZDT
migration algorithm (which requires
https://github.com/elastic/kibana/pull/153117 to be merged)
### Model version persistence schema.
*(This is what has also been named 'eviction schema' or 'known fields
schema'.)*
A new `SavedObjectsModelVersion.schemas.backwardConversion` property was
added to the model version definition.
This 'schema' can either be an arbitrary function, or a `schema.object`
from `@kbn/config-schema`
```ts
type SavedObjectModelVersionBackwardConversionSchema<
InAttrs = unknown,
OutAttrs = unknown
> = ObjectType | SavedObjectModelVersionBackwardConversionFn<InAttrs, OutAttrs>;
```
When specified for a version, the document's attributes will go thought
this schema during down conversions by the document migrator.
### Adapt the document migrator to support downward migrations for
documents of an higher version.
Add an `allowDowngrade` option to `DocumentMigrator.migrate` and
`KibanaMigrator.migrateDocument`. When this option is set to `true`, the
document migration will accept to 'downgrade' the document if necessary,
instead of throwing an error as done when the option is `false` or
unspecified (which was the only behavior prior to this PR's changes)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Add deferred migrations parameter.
* Update outdated documents query to take into account deferred migrations.
* Update outdated documents query to take into account the core migration version.
* Update read operations in the saved objects repository to perform deferred migrations.
## Summary
Changes the way model versions are defined, using a design more
appropriate to the iterative approach we decided to take regarding
delivering/exposing more capabilities to model versions.
A model version's changes is now defined by composition of multiple
low-level 'change' blocks (compared to high-level migration blocks as it
was previously designed).
This PR introduces the following type of 'model changes':
#### - `mappings_addition`
```ts
/**
* A {@link SavedObjectsModelChange | model change} adding new mappings.
*
* @remark when adding mappings, {@link SavedObjectsType.mappings | the type mappings} must also be updated accordingly.
* Overall, the type's mapping represents the latest version of the mappings, where the model changes
* represent the changes of mappings between two versions.
*
* @public
*/
export interface SavedObjectsModelMappingsAdditionChange {
type: 'mappings_addition';
/**
* The new mappings introduced in this version.
*/
addedMappings: SavedObjectsMappingProperties;
}
```
#### - `mappings_deprecation`
```ts
/**
* A {@link SavedObjectsModelChange | model change} flagging mappings as being deprecated.
* Deprecated mappings should no longer be used and will eventually be deleted later.
*/
export interface SavedObjectsModelMappingsDeprecationChange {
type: 'mappings_deprecation';
/**
* A list of paths to mappings to flag as deprecated.
*/
deprecatedMappings: string[];
}
```
#### - `data_backfill`
```ts
/**
* A {@link SavedObjectsModelChange | model change} used to backfill fields introduced in the same model version.
*
* @remark This type of model change should only be used to backfill newly introduced fields.
* Even if no check is performed to ensure that, using such transformations to mutate
* existing data of the document can lead to data corruption or inconsistency.
*/
export interface SavedObjectsModelDataBackfillChange<
PreviousAttributes = any,
NewAttributes = any
> {
type: 'data_backfill';
/**
* The backfill function to run.
*/
transform: SavedObjectModelDataBackfillFn<PreviousAttributes, NewAttributes>;
}
```
#### Example of definition
```ts
const myType = {
name: 'my_type',
mappings: {
properties: {
text: { type: 'text' },
keyword: { type: 'keyword' },
newField: { type: 'text' },
},
},
switchToModelVersionAt: '8.0.0',
modelVersions: {
0: {
changes: [],
},
1: {
changes: [
{
type: 'mappings_addition',
addedMappings: { newField: { type: 'text' } },
},
{
type: 'data_backfill',
transform: (doc) => {
return {
document: {
...doc,
attributes: {
...doc.attributes,
newField: `new ${doc.id}`,
},
},
};
},
},
],
},
},
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Description
Fix https://github.com/elastic/kibana/issues/104081
This PR move some of the SO types from the `.kibana` index into the
following ones:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
This split/reallocation will occur during the `8.8.0` Kibana upgrade
(*meaning: from any version older than `8.8.0` to any version greater or
equal to `8.8.0`*)
**This PR main changes are:**
- implement the changes required in the SO migration algorithm to
support this reallocation
- update the FTR tools (looking at you esArchiver) to support these new
indices
- update hardcoded references to `.kibana` and usage of the
`core.savedObjects.getKibanaIndex()` to use new APIs to target the
correct index/indices
- update FTR datasets, tests and utility accordingly
## To reviewers
**Overall estimated risk of regressions: low**
But, still, please take the time to review changes in your code. The
parts of the production code that were the most impacted are the
telemetry collectors, as most of them were performing direct requests
against the `.kibana` index, so we had to adapt them. Most other
contributor-owned changes are in FTR tests and datasets.
If you think a type is misplaced (either we missed some types that
should be moved to a specific index, or some types were moved and
shouldn't have been) please tell us, and we'll fix the reallocation
either in this PR or in a follow-up.
## .Kibana split
The following new indices are introduced by this PR, with the following
SO types being moved to it. (any SO type not listed here will be staying
in its current index)
Note: The complete **_type => index_** breakdown is available in [this
spreadsheet](https://docs.google.com/spreadsheets/d/1b_MG_E_aBksZ4Vkd9cVayij1oBpdhvH4XC8NVlChiio/edit#gid=145920788).
#### `.kibana_alerting_cases`
- action
- action_task_params
- alert
- api_key_pending_invalidation
- cases
- cases-comments
- cases-configure
- cases-connector-mappings
- cases-telemetry
- cases-user-actions
- connector_token
- rules-settings
- maintenance-window
#### `.kibana_security_solution`
- csp-rule-template
- endpoint:user-artifact
- endpoint:user-artifact-manifest
- exception-list
- exception-list-agnostic
- osquery-manager-usage-metric
- osquery-pack
- osquery-pack-asset
- osquery-saved-query
- security-rule
- security-solution-signals-migration
- siem-detection-engine-rule-actions
- siem-ui-timeline
- siem-ui-timeline-note
- siem-ui-timeline-pinned-event
#### `.kibana_analytics`
- canvas-element
- canvas-workpad-template
- canvas-workpad
- dashboard
- graph-workspace
- index-pattern
- kql-telemetry
- lens
- lens-ui-telemetry
- map
- search
- search-session
- search-telemetry
- visualization
#### `.kibana_ingest`
- epm-packages
- epm-packages-assets
- fleet-fleet-server-host
- fleet-message-signing-keys
- fleet-preconfiguration-deletion-record
- fleet-proxy
- ingest_manager_settings
- ingest-agent-policies
- ingest-download-sources
- ingest-outputs
- ingest-package-policies
## Tasks / PRs
### Sub-PRs
**Implementation**
- 🟣https://github.com/elastic/kibana/pull/154846
- 🟣https://github.com/elastic/kibana/pull/154892
- 🟣https://github.com/elastic/kibana/pull/154882
- 🟣https://github.com/elastic/kibana/pull/154884
- 🟣https://github.com/elastic/kibana/pull/155155
**Individual index split**
- 🟣https://github.com/elastic/kibana/pull/154897
- 🟣https://github.com/elastic/kibana/pull/155129
- 🟣https://github.com/elastic/kibana/pull/155140
- 🟣https://github.com/elastic/kibana/pull/155130
### Improvements / follow-ups
- 👷🏼 Extract logic into
[runV2Migration](https://github.com/elastic/kibana/pull/154151#discussion_r1158470566)
@gsoldevila
- Make `getCurrentIndexTypesMap` resillient to intermittent failures
https://github.com/elastic/kibana/pull/154151#discussion_r1169289717
- 🚧 Build a more structured
[MigratorSynchronizer](https://github.com/elastic/kibana/pull/154151#discussion_r1158469918)
- 🟣https://github.com/elastic/kibana/pull/155035
- 🟣https://github.com/elastic/kibana/pull/155116
- 🟣https://github.com/elastic/kibana/pull/155366
## Reallocation tweaks
Tweaks to the reallocation can be done after the initial merge, as long
as it's done before the public release of 8.8
- `url` should get back to `.kibana` (see
[comment](https://github.com/elastic/kibana/pull/154888#discussion_r1172317133))
## Release Note
For performance purposes, Kibana is now using more system indices to
store its internal data.
The following system indices will be created when upgrading to `8.8.0`:
- `.kibana_alerting_cases`
- `.kibana_analytics`
- `.kibana_security_solution`
- `.kibana_ingest`
---------
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Georgii Gorbachev <georgii.gorbachev@elastic.co>
## 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
After merging https://github.com/elastic/kibana/pull/148979 there are a
few interfaces in the server-side code that export a reference to a
deprecated SO type.
In this PR we fix them by updating a few imports to use the
non-deprecated SO type. Additionally, we resolve a potential circular
reference issue between `core-saved-objects-server` and
`core-saved-objects-api-server` by "moving" saved objects and related
types exports to `core-saved-objects-api-server`
Closes#147049Closes#149897
Migrates authorization and audit logic from the Saved Objects Repository
to the Saved Objects Security Extension. This is achieved by
implementing action-specific authorization methods within the security
extension. The SO repository is no longer responsible for making any
authorization decisions, but It is still responsible to know how to call
the extension methods. I've tried to make this as straightforward as
possible such that there is a clear ownership delineation between the
repository and the extension, by keeping the interface simple and
(hopefully) obvious.
### Security Extension Interface
New Public Extension Methods:
- authorizeCreate
- authorizeBulkCreate
- authorizeUpdate
- authorizeBulkUpdate
- authorizeDelete
- authorizeBulkDelete
- authorizeGet
- authorizeBulkGet
- authorizeCheckConflicts
- authorizeRemoveReferences
- authorizeOpenPointInTime
- auditClosePointInTime
- authorizeAndRedactMultiNamespaceReferences
- authorizeAndRedactInternalBulkResolve
- authorizeUpdateSpaces
- authorizeFind
- getFindRedactTypeMap
- authorizeDisableLegacyUrlAliases (for secure spaces client)
- auditObjectsForSpaceDeletion (for secure spaces client)
Removed from public interface:
- authorize
- enforceAuthorization
- addAuditEvent
### Tests
- Most test coverage moved from `repository.security_extension.test.ts`
to `saved_objects_security_extension.test.ts`
- `repository.security_extension.test.ts` tests extension call,
parameters, and return
- Updates repository unit tests to check that all security extension
calls are made with the current space when the spaces extension is also
enabled
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/150301
- Add logic to converts model version transformations to the format used
by the document migrator
- Use in when preparing migration data for the document migrator
- Improve the migration validation logic to take model versions into
account (and clean it)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/150297
First step toward managed upgrades
This PR adds the types that will be used for the new SO model version
API, and adds the new properties to the `SavedObjectsType` type.
The implementation is outside of scope of the PR and will be implemented
in a future PR.
The PR also adapt the `check_registered_types` test to trigger a review
when the attributes of `SavedObjectsType` introduced in this PR are
changed.
## Summary
After merging https://github.com/elastic/kibana/pull/148979 there are a
number of imports that can be fixed immediately to address our new
deprecation notice.
## To Core reviewers
The package `core-saved-objects-server` is using types from
`core-saved-objects-api-server` which creates a circular dependency when
using `SavedObject` type from it's new home in
`core-saved-object-server`:
`core-saved-objects-server` -> `core-saved-objects-api-server` ->
`core-saved-objects-server`
One solution is that we can create a new package
`packages/core/saved-objects/core-saved-objects-server-shared` that will
only hold the `SavedObject` type and a select few others. I'm not sure
what the best approach here is. I have left
`core-saved-objects-api-server` unchanged for now (i.e., it is still
importing `SavedObject` from `common` which is deprecated).
Any input would be greatly appreciated!
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
* Re-exporting SO types from `common` inside server code
* Deprecated individual APIs on interfaces, not just interfaces, to make
deprecation visible to consumers
* Deprecates the `savedObjects` prop on the `CoreStart` interface too
## Summary
In the near future we will remove Saved Object (SO) HTTP APIs. This PR
deprecates all browser-side SO types and interfaces.
General comments on the approach taken here:
* Add a deprecation notice that links to a GitHub issue that can be
referenced by all teams
* Do not break existing imports/exports
* Mocks are also an indication of SO browser-side use, added deprecation
notices
* Some common types must also be deprecated, some may remain. For those
to be removed they are moved to a separate file, with a deprecated
type-alias re-exported
## Notes to reviewers
* Easiest way to get an overview of the changes is to have the file-tree
open in the "Files changed" view
* Are there any other ways browser-side code can get knowledge of Saved
Objects?
* Please go through some client code and test that the DX is working as
expected (the GitHub issue is discoverable)
## Related
* https://github.com/elastic/kibana/issues/147150
* https://github.com/elastic/dev/issues/2194
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Dearest Reviewers 👋
I've been working on this branch with @mistic and @tylersmalley and
we're really confident in these changes. Additionally, this changes code
in nearly every package in the repo so we don't plan to wait for reviews
to get in before merging this. If you'd like to have a concern
addressed, please feel free to leave a review, but assuming that nobody
raises a blocker in the next 24 hours we plan to merge this EOD pacific
tomorrow, 12/22.
We'll be paying close attention to any issues this causes after merging
and work on getting those fixed ASAP. 🚀
---
The operations team is not confident that we'll have the time to achieve
what we originally set out to accomplish by moving to Bazel with the
time and resources we have available. We have also bought ourselves some
headroom with improvements to babel-register, optimizer caching, and
typescript project structure.
In order to make sure we deliver packages as quickly as possible (many
teams really want them), with a usable and familiar developer
experience, this PR removes Bazel for building packages in favor of
using the same JIT transpilation we use for plugins.
Additionally, packages now use `kbn_references` (again, just copying the
dx from plugins to packages).
Because of the complex relationships between packages/plugins and in
order to prepare ourselves for automatic dependency detection tools we
plan to use in the future, this PR also introduces a "TS Project Linter"
which will validate that every tsconfig.json file meets a few
requirements:
1. the chain of base config files extended by each config includes
`tsconfig.base.json` and not `tsconfig.json`
1. the `include` config is used, and not `files`
2. the `exclude` config includes `target/**/*`
3. the `outDir` compiler option is specified as `target/types`
1. none of these compiler options are specified: `declaration`,
`declarationMap`, `emitDeclarationOnly`, `skipLibCheck`, `target`,
`paths`
4. all references to other packages/plugins use their pkg id, ie:
```js
// valid
{
"kbn_references": ["@kbn/core"]
}
// not valid
{
"kbn_references": [{ "path": "../../../src/core/tsconfig.json" }]
}
```
5. only packages/plugins which are imported somewhere in the ts code are
listed in `kbn_references`
This linter is not only validating all of the tsconfig.json files, but
it also will fix these config files to deal with just about any
violation that can be produced. Just run `node scripts/ts_project_linter
--fix` locally to apply these fixes, or let CI take care of
automatically fixing things and pushing the changes to your PR.
> **Example:** [`64e93e5`
(#146212)](64e93e5806)
When I merged main into my PR it included a change which removed the
`@kbn/core-injected-metadata-browser` package. After resolving the
conflicts I missed a few tsconfig files which included references to the
now removed package. The TS Project Linter identified that these
references were removed from the code and pushed a change to the PR to
remove them from the tsconfig.json files.
## No bazel? Does that mean no packages??
Nope! We're still doing packages but we're pretty sure now that we won't
be using Bazel to accomplish the 'distributed caching' and 'change-based
tasks' portions of the packages project.
This PR actually makes packages much easier to work with and will be
followed up with the bundling benefits described by the original
packages RFC. Then we'll work on documentation and advocacy for using
packages for any and all new code.
We're pretty confident that implementing distributed caching and
change-based tasks will be necessary in the future, but because of
recent improvements in the repo we think we can live without them for
**at least** a year.
## Wait, there are still BUILD.bazel files in the repo
Yes, there are still three webpack bundles which are built by Bazel: the
`@kbn/ui-shared-deps-npm` DLL, `@kbn/ui-shared-deps-src` externals, and
the `@kbn/monaco` workers. These three webpack bundles are still created
during bootstrap and remotely cached using bazel. The next phase of this
project is to figure out how to get the package bundling features
described in the RFC with the current optimizer, and we expect these
bundles to go away then. Until then any package that is used in those
three bundles still needs to have a BUILD.bazel file so that they can be
referenced by the remaining webpack builds.
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Merges the changes of #134395 into the new packages structure.
Resolves#133835
### Description
This PR represents a fully manual merge of the saved objects refactor of
client wrapper system into repository extensions. These changes are
being manually merged due to significant changes of the saved objects
implementation in the main branch, specifically the migration to the new
packages structure.
### Other changes
- Bulk Delete: bulk delete was implemented in parallel to #134395 being
completed and this PR will refactor that API to utilize the new
extensions
Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
* [packages] add kibana.jsonc files
* auto-migrate to kibana.jsonc
* support interactive pkg id selection too
* remove old codeowners entry
* skip codeowners generation when .github/CODEOWNERS doesn't exist
* fall back to format validation if user is offline
* update question style
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* refact(NA): apply root_input_dir=src to each already created pkg
* refact(NA): update package generator
* fix(NA): correctly use rootDir
* fix(NA): use root input dir on latest introduced pkgs for jsts_transpiler macro
* chore(NA): merge with main
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
