# Backport
This will backport the following commits from `main` to `8.x`:
- [feat: allow plugins to deprecate and replace features and feature
privileges (#186800)](https://github.com/elastic/kibana/pull/186800)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Aleh
Zasypkin","email":"aleh.zasypkin@elastic.co"},"sourceCommit":{"committedDate":"2024-10-14T19:40:59Z","message":"feat:
allow plugins to deprecate and replace features and feature privileges
(#186800)\n\n## Summary\r\n\r\nThis change is the implementation of the
`Kibana Privilege Migrations`\r\nproposal/RFC and provides a framework
that allows developers to replace\r\nan existing feature with a new one
that has the desired configuration\r\nwhile teaching the platform how
the privileges of the deprecated feature\r\ncan be represented by
non-deprecated ones. This approach avoids\r\nintroducing breaking
changes for users who still rely on the deprecated\r\nprivileges in
their existing roles and any automation.\r\n\r\nAmong the use cases the
framework is supposed to handle, the most common\r\nare the
following:\r\n\r\n* Changing a feature ID from `Alpha` to `Beta`\r\n*
Splitting a feature `Alpha` into two features, `Beta` and `Gamma`\r\n*
Moving a capability between privileges within a feature (top-level
or\r\nsub-feature)\r\n* Consolidating capabilities across independent
features\r\n\r\n## Scope\r\n\r\nThis PR includes only the core
functionality proposed in the RFC and\r\nmost of the necessary
guardrails (tests, early validations, etc.) to\r\nhelp engineers start
planning and implementing their migrations as soon\r\nas possible. The
following functionality will be added in follow-ups or\r\nonce we
collect enough feedback:\r\n\r\n* Telemetry\r\n* Developer
documentation\r\n* UI enhancements (highlighting roles with deprecated
privileges and\r\nmanual migration actions)\r\n\r\n##
Framework\r\n\r\nThe steps below use a scenario where a feature `Alpha`
should be split\r\ninto two other features `Beta` and `Gamma` as an
example.\r\n\r\n### Step 1: Create new features with the desired
privileges\r\n\r\nFirst of all, define new feature or features with the
desired\r\nconfiguration as you'd do before. There are no constraints
here.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
id: 'feature_beta',\r\n name: 'Feature Beta',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_1'], read: [] },\r\n ui:
['ui_all'],\r\n api: ['api_all'],\r\n … omitted for brevity …\r\n },\r\n
read: {\r\n savedObject: { all: [], read: ['saved_object_1'] },\r\n ui:
['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity …\r\n
},\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_gamma',\r\n name: 'Feature Gamma',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_2'], read: [] },\r\n ui:
['ui_all'],\r\n // Note that Feature Gamma, unlike Features Alpha and
Beta doesn't provide any API access tags\r\n … omitted for brevity …\r\n
},\r\n read: {\r\n savedObject: { all: [], read: ['saved_object_2']
},\r\n ui: ['ui_read'],\r\n // Note that Feature Gamma, unlike Features
Alpha and Beta doesn't provide any API access tags\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 2: Mark existing
feature as deprecated\r\n\r\nOnce a feature is marked as deprecated, it
should essentially be treated\r\nas frozen for backward compatibility
reasons. Deprecated features will\r\nno longer be available through the
Kibana role management UI and will be\r\nreplaced with non-deprecated
privileges.\r\n\r\nDeprecated privileges will still be accepted if the
role is created or\r\nupdated via the Kibana role management APIs to
avoid disrupting existing\r\nuser automation.\r\n\r\nTo avoid breaking
existing roles that reference privileges provided by\r\nthe deprecated
features, Kibana will continue registering these\r\nprivileges as
Elasticsearch application
privileges.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity
…\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n</details>\r\n\r\n### Step 3: Map deprecated
feature’s privileges to the privileges of the\r\nnon-deprecated
features\r\n\r\nThe important requirement for a successful migration
from a deprecated\r\nfeature to a new feature or features is that it
should be possible to\r\nexpress **any combination** of the deprecated
feature and sub-feature\r\nprivileges with the feature or sub-feature
privileges of non-deprecated\r\nfeatures. This way, while editing a role
with deprecated feature\r\nprivileges in the UI, the admin will be
interacting with new privileges\r\nas if they were creating a new role
from scratch, maintaining\r\nconsistency.\r\n\r\nThe relationship
between the privileges of the deprecated feature and\r\nthe privileges
of the features that are supposed to replace them is\r\nexpressed with a
new `replacedBy` property available on the privileges\r\nof the
deprecated feature.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n { feature: 'feature_gamma', privileges:
['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n replacedBy: [\r\n {
feature: 'feature_beta', privileges: ['read'] },\r\n { feature:
'feature_gamma', privileges: ['read'] },\r\n\t],\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 4: Adjust the code to
rely only on new, non-deprecated features\r\n\r\nSpecial care should be
taken if the replacement privileges cannot reuse\r\nthe API access tags
from the deprecated privileges and introduce new\r\ntags that will be
applied to the same API endpoints. In this case,\r\ndevelopers should
replace the API access tags of the deprecated\r\nprivileges with the
corresponding tags provided by the replacement\r\nprivileges. This is
necessary because API endpoints can only be accessed\r\nif the user
privileges cover all the tags listed in the API endpoint\r\ndefinition,
and without these changes, existing roles referencing\r\ndeprecated
privileges won’t be able to access those endpoints.\r\n\r\nThe UI
capabilities are handled slightly differently because they are\r\nalways
prefixed with the feature ID. When migrating to new features with\r\nnew
IDs, the code that interacts with UI capabilities will be updated
to\r\nuse these new feature IDs.\r\n\r\n<details>\r\n\r\n<summary>Click
to see the code</summary>\r\n\r\n```ts\r\n// BEFORE
deprecation/migration\r\n// 1. Feature Alpha defition (not deprecated
yet)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_alpha',\r\n privileges: {\r\n all: {\r\n api: ['api_all'],\r\n
… omitted for brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\n// 2. Route protected by `all` privilege of the Feature
Alpha\r\nrouter.post(\r\n { path: '/api/domain/my_api', options: { tags:
['access:api_all'] } },\r\n async (_context, request, response) =>
{}\r\n);\r\n\r\n// AFTER deprecation/migration\r\n// 1. Feature Alpha
defition (deprecated, with updated API
tags)\r\ndeps.features.registerKibanaFeature({\r\n deprecated: …,\r\n
id: 'feature_alpha',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n
},\r\n … omitted for brevity …\r\n});\r\n\r\n// 2. Feature Beta defition
(new)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_beta',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n … omitted for brevity …\r\n }\r\n },\r\n … omitted
for brevity …\r\n});\r\n\r\n// 3. Route protected by `all` privilege of
the Feature Alpha OR Feature Beta\r\nrouter.post(\r\n { path:
'/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },\r\n
async (_context, request, response) => {}\r\n);\r\n\r\n----\r\n\r\n// ❌
Old client-side code (supports only deprecated privileges)\r\nif
(capabilities.feature_alpha.ui_all) {\r\n … omitted for brevity
…\r\n}\r\n\r\n// ✅ New client-side code (will work for **both** new and
deprecated privileges)\r\nif (capabilities.feature_beta.ui_all) {\r\n …
omitted for brevity …\r\n}\r\n```\r\n</details>\r\n\r\n## How to
test\r\n\r\nThe code introduces a set of API integration tests that are
designed to\r\nvalidate whether the privilege mapping between deprecated
and\r\nreplacement privileges maintains backward
compatibility.\r\n\r\nYou can run the test server with the following
config to register a\r\nnumber of [example
deprecated\r\nfeatures](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)\r\nand
the features that replace them, to see the framework in
action:\r\n\r\n```bash\r\nnode scripts/functional_tests_server.js
--config
x-pack/test/security_api_integration/features.config.ts\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"cb2112cae51d5f69b9e47ebfde66cfacb2a6719b","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Security","release_note:skip","Feature:Security/Authorization","v9.0.0","backport:prev-minor","v8.16.0"],"number":186800,"url":"https://github.com/elastic/kibana/pull/186800","mergeCommit":{"message":"feat:
allow plugins to deprecate and replace features and feature privileges
(#186800)\n\n## Summary\r\n\r\nThis change is the implementation of the
`Kibana Privilege Migrations`\r\nproposal/RFC and provides a framework
that allows developers to replace\r\nan existing feature with a new one
that has the desired configuration\r\nwhile teaching the platform how
the privileges of the deprecated feature\r\ncan be represented by
non-deprecated ones. This approach avoids\r\nintroducing breaking
changes for users who still rely on the deprecated\r\nprivileges in
their existing roles and any automation.\r\n\r\nAmong the use cases the
framework is supposed to handle, the most common\r\nare the
following:\r\n\r\n* Changing a feature ID from `Alpha` to `Beta`\r\n*
Splitting a feature `Alpha` into two features, `Beta` and `Gamma`\r\n*
Moving a capability between privileges within a feature (top-level
or\r\nsub-feature)\r\n* Consolidating capabilities across independent
features\r\n\r\n## Scope\r\n\r\nThis PR includes only the core
functionality proposed in the RFC and\r\nmost of the necessary
guardrails (tests, early validations, etc.) to\r\nhelp engineers start
planning and implementing their migrations as soon\r\nas possible. The
following functionality will be added in follow-ups or\r\nonce we
collect enough feedback:\r\n\r\n* Telemetry\r\n* Developer
documentation\r\n* UI enhancements (highlighting roles with deprecated
privileges and\r\nmanual migration actions)\r\n\r\n##
Framework\r\n\r\nThe steps below use a scenario where a feature `Alpha`
should be split\r\ninto two other features `Beta` and `Gamma` as an
example.\r\n\r\n### Step 1: Create new features with the desired
privileges\r\n\r\nFirst of all, define new feature or features with the
desired\r\nconfiguration as you'd do before. There are no constraints
here.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
id: 'feature_beta',\r\n name: 'Feature Beta',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_1'], read: [] },\r\n ui:
['ui_all'],\r\n api: ['api_all'],\r\n … omitted for brevity …\r\n },\r\n
read: {\r\n savedObject: { all: [], read: ['saved_object_1'] },\r\n ui:
['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity …\r\n
},\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_gamma',\r\n name: 'Feature Gamma',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_2'], read: [] },\r\n ui:
['ui_all'],\r\n // Note that Feature Gamma, unlike Features Alpha and
Beta doesn't provide any API access tags\r\n … omitted for brevity …\r\n
},\r\n read: {\r\n savedObject: { all: [], read: ['saved_object_2']
},\r\n ui: ['ui_read'],\r\n // Note that Feature Gamma, unlike Features
Alpha and Beta doesn't provide any API access tags\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 2: Mark existing
feature as deprecated\r\n\r\nOnce a feature is marked as deprecated, it
should essentially be treated\r\nas frozen for backward compatibility
reasons. Deprecated features will\r\nno longer be available through the
Kibana role management UI and will be\r\nreplaced with non-deprecated
privileges.\r\n\r\nDeprecated privileges will still be accepted if the
role is created or\r\nupdated via the Kibana role management APIs to
avoid disrupting existing\r\nuser automation.\r\n\r\nTo avoid breaking
existing roles that reference privileges provided by\r\nthe deprecated
features, Kibana will continue registering these\r\nprivileges as
Elasticsearch application
privileges.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity
…\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n</details>\r\n\r\n### Step 3: Map deprecated
feature’s privileges to the privileges of the\r\nnon-deprecated
features\r\n\r\nThe important requirement for a successful migration
from a deprecated\r\nfeature to a new feature or features is that it
should be possible to\r\nexpress **any combination** of the deprecated
feature and sub-feature\r\nprivileges with the feature or sub-feature
privileges of non-deprecated\r\nfeatures. This way, while editing a role
with deprecated feature\r\nprivileges in the UI, the admin will be
interacting with new privileges\r\nas if they were creating a new role
from scratch, maintaining\r\nconsistency.\r\n\r\nThe relationship
between the privileges of the deprecated feature and\r\nthe privileges
of the features that are supposed to replace them is\r\nexpressed with a
new `replacedBy` property available on the privileges\r\nof the
deprecated feature.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n { feature: 'feature_gamma', privileges:
['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n replacedBy: [\r\n {
feature: 'feature_beta', privileges: ['read'] },\r\n { feature:
'feature_gamma', privileges: ['read'] },\r\n\t],\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 4: Adjust the code to
rely only on new, non-deprecated features\r\n\r\nSpecial care should be
taken if the replacement privileges cannot reuse\r\nthe API access tags
from the deprecated privileges and introduce new\r\ntags that will be
applied to the same API endpoints. In this case,\r\ndevelopers should
replace the API access tags of the deprecated\r\nprivileges with the
corresponding tags provided by the replacement\r\nprivileges. This is
necessary because API endpoints can only be accessed\r\nif the user
privileges cover all the tags listed in the API endpoint\r\ndefinition,
and without these changes, existing roles referencing\r\ndeprecated
privileges won’t be able to access those endpoints.\r\n\r\nThe UI
capabilities are handled slightly differently because they are\r\nalways
prefixed with the feature ID. When migrating to new features with\r\nnew
IDs, the code that interacts with UI capabilities will be updated
to\r\nuse these new feature IDs.\r\n\r\n<details>\r\n\r\n<summary>Click
to see the code</summary>\r\n\r\n```ts\r\n// BEFORE
deprecation/migration\r\n// 1. Feature Alpha defition (not deprecated
yet)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_alpha',\r\n privileges: {\r\n all: {\r\n api: ['api_all'],\r\n
… omitted for brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\n// 2. Route protected by `all` privilege of the Feature
Alpha\r\nrouter.post(\r\n { path: '/api/domain/my_api', options: { tags:
['access:api_all'] } },\r\n async (_context, request, response) =>
{}\r\n);\r\n\r\n// AFTER deprecation/migration\r\n// 1. Feature Alpha
defition (deprecated, with updated API
tags)\r\ndeps.features.registerKibanaFeature({\r\n deprecated: …,\r\n
id: 'feature_alpha',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n
},\r\n … omitted for brevity …\r\n});\r\n\r\n// 2. Feature Beta defition
(new)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_beta',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n … omitted for brevity …\r\n }\r\n },\r\n … omitted
for brevity …\r\n});\r\n\r\n// 3. Route protected by `all` privilege of
the Feature Alpha OR Feature Beta\r\nrouter.post(\r\n { path:
'/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },\r\n
async (_context, request, response) => {}\r\n);\r\n\r\n----\r\n\r\n// ❌
Old client-side code (supports only deprecated privileges)\r\nif
(capabilities.feature_alpha.ui_all) {\r\n … omitted for brevity
…\r\n}\r\n\r\n// ✅ New client-side code (will work for **both** new and
deprecated privileges)\r\nif (capabilities.feature_beta.ui_all) {\r\n …
omitted for brevity …\r\n}\r\n```\r\n</details>\r\n\r\n## How to
test\r\n\r\nThe code introduces a set of API integration tests that are
designed to\r\nvalidate whether the privilege mapping between deprecated
and\r\nreplacement privileges maintains backward
compatibility.\r\n\r\nYou can run the test server with the following
config to register a\r\nnumber of [example
deprecated\r\nfeatures](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)\r\nand
the features that replace them, to see the framework in
action:\r\n\r\n```bash\r\nnode scripts/functional_tests_server.js
--config
x-pack/test/security_api_integration/features.config.ts\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"cb2112cae51d5f69b9e47ebfde66cfacb2a6719b"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/186800","number":186800,"mergeCommit":{"message":"feat:
allow plugins to deprecate and replace features and feature privileges
(#186800)\n\n## Summary\r\n\r\nThis change is the implementation of the
`Kibana Privilege Migrations`\r\nproposal/RFC and provides a framework
that allows developers to replace\r\nan existing feature with a new one
that has the desired configuration\r\nwhile teaching the platform how
the privileges of the deprecated feature\r\ncan be represented by
non-deprecated ones. This approach avoids\r\nintroducing breaking
changes for users who still rely on the deprecated\r\nprivileges in
their existing roles and any automation.\r\n\r\nAmong the use cases the
framework is supposed to handle, the most common\r\nare the
following:\r\n\r\n* Changing a feature ID from `Alpha` to `Beta`\r\n*
Splitting a feature `Alpha` into two features, `Beta` and `Gamma`\r\n*
Moving a capability between privileges within a feature (top-level
or\r\nsub-feature)\r\n* Consolidating capabilities across independent
features\r\n\r\n## Scope\r\n\r\nThis PR includes only the core
functionality proposed in the RFC and\r\nmost of the necessary
guardrails (tests, early validations, etc.) to\r\nhelp engineers start
planning and implementing their migrations as soon\r\nas possible. The
following functionality will be added in follow-ups or\r\nonce we
collect enough feedback:\r\n\r\n* Telemetry\r\n* Developer
documentation\r\n* UI enhancements (highlighting roles with deprecated
privileges and\r\nmanual migration actions)\r\n\r\n##
Framework\r\n\r\nThe steps below use a scenario where a feature `Alpha`
should be split\r\ninto two other features `Beta` and `Gamma` as an
example.\r\n\r\n### Step 1: Create new features with the desired
privileges\r\n\r\nFirst of all, define new feature or features with the
desired\r\nconfiguration as you'd do before. There are no constraints
here.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
id: 'feature_beta',\r\n name: 'Feature Beta',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_1'], read: [] },\r\n ui:
['ui_all'],\r\n api: ['api_all'],\r\n … omitted for brevity …\r\n },\r\n
read: {\r\n savedObject: { all: [], read: ['saved_object_1'] },\r\n ui:
['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity …\r\n
},\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_gamma',\r\n name: 'Feature Gamma',\r\n privileges: {\r\n all:
{\r\n savedObject: { all: ['saved_object_2'], read: [] },\r\n ui:
['ui_all'],\r\n // Note that Feature Gamma, unlike Features Alpha and
Beta doesn't provide any API access tags\r\n … omitted for brevity …\r\n
},\r\n read: {\r\n savedObject: { all: [], read: ['saved_object_2']
},\r\n ui: ['ui_read'],\r\n // Note that Feature Gamma, unlike Features
Alpha and Beta doesn't provide any API access tags\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 2: Mark existing
feature as deprecated\r\n\r\nOnce a feature is marked as deprecated, it
should essentially be treated\r\nas frozen for backward compatibility
reasons. Deprecated features will\r\nno longer be available through the
Kibana role management UI and will be\r\nreplaced with non-deprecated
privileges.\r\n\r\nDeprecated privileges will still be accepted if the
role is created or\r\nupdated via the Kibana role management APIs to
avoid disrupting existing\r\nuser automation.\r\n\r\nTo avoid breaking
existing roles that reference privileges provided by\r\nthe deprecated
features, Kibana will continue registering these\r\nprivileges as
Elasticsearch application
privileges.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n … omitted for brevity
…\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n</details>\r\n\r\n### Step 3: Map deprecated
feature’s privileges to the privileges of the\r\nnon-deprecated
features\r\n\r\nThe important requirement for a successful migration
from a deprecated\r\nfeature to a new feature or features is that it
should be possible to\r\nexpress **any combination** of the deprecated
feature and sub-feature\r\nprivileges with the feature or sub-feature
privileges of non-deprecated\r\nfeatures. This way, while editing a role
with deprecated feature\r\nprivileges in the UI, the admin will be
interacting with new privileges\r\nas if they were creating a new role
from scratch, maintaining\r\nconsistency.\r\n\r\nThe relationship
between the privileges of the deprecated feature and\r\nthe privileges
of the features that are supposed to replace them is\r\nexpressed with a
new `replacedBy` property available on the privileges\r\nof the
deprecated feature.\r\n\r\n<details>\r\n\r\n<summary>Click to see the
code</summary>\r\n\r\n```ts\r\ndeps.features.registerKibanaFeature({\r\n
// This is a new `KibanaFeature` property available during feature
registration.\r\n deprecated: {\r\n // User-facing justification for
privilege deprecation that we can display\r\n // to the user when we ask
them to perform role migration.\r\n notice:
i18n.translate('xpack.security...', {\r\n defaultMessage: \"Feature
Alpha is deprecated, refer to {link}...\",\r\n values: { link:
docLinks.links.security.deprecatedFeatureAlpha },\r\n })\r\n },\r\n //
Feature id should stay unchanged, and it's not possible to reuse it.\r\n
id: 'feature_alpha',\r\n name: 'Feature Alpha (DEPRECATED)',\r\n
privileges: {\r\n all: {\r\n savedObject: { all: ['saved_object_1',
'saved_object_2'], read: [] },\r\n ui: ['ui_all'],\r\n api:
['api_all'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n { feature: 'feature_gamma', privileges:
['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n read: {\r\n
savedObject: { all: [], read: ['saved_object_1', 'saved_object_2']
},\r\n ui: ['ui_read'],\r\n api: ['api_read'],\r\n replacedBy: [\r\n {
feature: 'feature_beta', privileges: ['read'] },\r\n { feature:
'feature_gamma', privileges: ['read'] },\r\n\t],\r\n … omitted for
brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n```\r\n\r\n</details>\r\n\r\n### Step 4: Adjust the code to
rely only on new, non-deprecated features\r\n\r\nSpecial care should be
taken if the replacement privileges cannot reuse\r\nthe API access tags
from the deprecated privileges and introduce new\r\ntags that will be
applied to the same API endpoints. In this case,\r\ndevelopers should
replace the API access tags of the deprecated\r\nprivileges with the
corresponding tags provided by the replacement\r\nprivileges. This is
necessary because API endpoints can only be accessed\r\nif the user
privileges cover all the tags listed in the API endpoint\r\ndefinition,
and without these changes, existing roles referencing\r\ndeprecated
privileges won’t be able to access those endpoints.\r\n\r\nThe UI
capabilities are handled slightly differently because they are\r\nalways
prefixed with the feature ID. When migrating to new features with\r\nnew
IDs, the code that interacts with UI capabilities will be updated
to\r\nuse these new feature IDs.\r\n\r\n<details>\r\n\r\n<summary>Click
to see the code</summary>\r\n\r\n```ts\r\n// BEFORE
deprecation/migration\r\n// 1. Feature Alpha defition (not deprecated
yet)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_alpha',\r\n privileges: {\r\n all: {\r\n api: ['api_all'],\r\n
… omitted for brevity …\r\n },\r\n },\r\n … omitted for brevity
…\r\n});\r\n\r\n// 2. Route protected by `all` privilege of the Feature
Alpha\r\nrouter.post(\r\n { path: '/api/domain/my_api', options: { tags:
['access:api_all'] } },\r\n async (_context, request, response) =>
{}\r\n);\r\n\r\n// AFTER deprecation/migration\r\n// 1. Feature Alpha
defition (deprecated, with updated API
tags)\r\ndeps.features.registerKibanaFeature({\r\n deprecated: …,\r\n
id: 'feature_alpha',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n replacedBy: [\r\n { feature: 'feature_beta',
privileges: ['all'] },\r\n ],\r\n … omitted for brevity …\r\n },\r\n
},\r\n … omitted for brevity …\r\n});\r\n\r\n// 2. Feature Beta defition
(new)\r\ndeps.features.registerKibanaFeature({\r\n id:
'feature_beta',\r\n privileges: {\r\n all: {\r\n api:
['api_all_v2'],\r\n … omitted for brevity …\r\n }\r\n },\r\n … omitted
for brevity …\r\n});\r\n\r\n// 3. Route protected by `all` privilege of
the Feature Alpha OR Feature Beta\r\nrouter.post(\r\n { path:
'/api/domain/my_api', options: { tags: ['access:api_all_v2'] } },\r\n
async (_context, request, response) => {}\r\n);\r\n\r\n----\r\n\r\n// ❌
Old client-side code (supports only deprecated privileges)\r\nif
(capabilities.feature_alpha.ui_all) {\r\n … omitted for brevity
…\r\n}\r\n\r\n// ✅ New client-side code (will work for **both** new and
deprecated privileges)\r\nif (capabilities.feature_beta.ui_all) {\r\n …
omitted for brevity …\r\n}\r\n```\r\n</details>\r\n\r\n## How to
test\r\n\r\nThe code introduces a set of API integration tests that are
designed to\r\nvalidate whether the privilege mapping between deprecated
and\r\nreplacement privileges maintains backward
compatibility.\r\n\r\nYou can run the test server with the following
config to register a\r\nnumber of [example
deprecated\r\nfeatures](https://github.com/elastic/kibana/pull/186800/files#diff-d887981d43bbe30cda039340b906b0fa7649ba80230be4de8eda326036f10f6fR20-R49)(`x-pack/test/security_api_integration/plugins/features_provider/server/index.ts`)\r\nand
the features that replace them, to see the framework in
action:\r\n\r\n```bash\r\nnode scripts/functional_tests_server.js
--config
x-pack/test/security_api_integration/features.config.ts\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"cb2112cae51d5f69b9e47ebfde66cfacb2a6719b"}},{"branch":"8.x","label":"v8.16.0","labelRegex":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
# Backport
This will backport the following commits from `main` to `8.x`:
- [Added scope field to features config.
(#191634)](https://github.com/elastic/kibana/pull/191634)
<!--- Backport version: 8.9.8 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Elena
Shostak","email":"165678770+elena-shostak@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-09-13T00:22:20Z","message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","chore","Team:Security","Feature:Security/Spaces","backport:skip","Team:Fleet","v9.0.0","Team:Obs
AI
Assistant","ci:project-deploy-observability","Team:obs-ux-infra_services","Team:obs-ux-management","apm:review"],"number":191634,"url":"https://github.com/elastic/kibana/pull/191634","mergeCommit":{"message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/191634","number":191634,"mergeCommit":{"message":"Added
scope field to features config. (#191634)\n\n## Summary\r\nKibana needs
to more tightly control the set of visible features within\r\na space,
in order to support the new solution-based navigation.\r\nAdded `scope`
field to the features configuration. This enhancement is\r\nintended to
prevent new features from appearing in Space
Visibility\r\nToggles.\r\n\r\n\r\n### Checklist\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n- [x] [Unit
or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n\r\n__Fixes:
https://github.com/elastic/kibana/issues/191299__\r\n\r\n## Release
Note\r\n\r\nAdded `scope` field to the features configuration. This
enhancement is\r\nintended to prevent new features from appearing in
Space Visibility\r\nToggles.\r\n\r\n---------\r\n\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"a71c9ba38ab4b88288313b91bd1b699777b3aab1"}}]}]
BACKPORT-->
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/183687
## Feature
- Implement dashboard view stats UI on top of usage counter that counts
dashboard views for last 90 day and shows weekly histogram.
- (Even if there is not a lot of data, we still show it as a weekly
histogram, so it can be pretty empty intially)
## Implementation
### Server side
Dashboard plugin registers new routes to increase the view count and get
stats. Routes are protected for users with dashboard access only. The
implementation is located in
`@kbn/content-management-content-insights-server` and internally uses
usage counters. The retention is 90 days, so we can only show stats for
last 90 days.
### Client side
- Dashboard uses the client from
`@kbn/content-management-content-insights-public` to increase the view
count every time a user opens a dashboard.
- TableListView opens the flyout from
`@kbn/content-management-content-insights-public`to display the stats
## How to test
- For new views just open a dashboard and check that view stat is
increased
- For old views you can populate the usage counters with historic data.
I used the following script:
https://gist.github.com/Dosant/425042fcf75d5e40e5a46374f6234a54
## Summary
Fix https://github.com/elastic/kibana/issues/65999
Change the `features` plugin's contract type names to follow our naming
convensions and to avoid needing to rename them during imports
(and yeah, I'm triggering a review from 30 teams again for a type
rename, just for the fun of it)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR extends the features plugin to accept feature definition
overrides via Kibana configuration. The functionality is limited to the
Serverless offering only. Additionally, the PR updates Kibana serverless
configurations to include overrides based on the "simplified feature
toggles" proposals discussed with the solution teams.
The configuration might look like this:
```yaml
## Fine-tune the feature privileges.
xpack.features.overrides:
dashboard:
privileges:
### Dashboard's `All` feature privilege should implicitly
### grant `All` access to Maps and Visualize features.
all.composedOf:
- feature: "maps"
privileges: [ "all" ]
- feature: "visualize"
privileges: [ "all" ]
### All Dashboard sub-feature privileges should be hidden:
### reporting capabilities will be granted via dedicated
### Reporting feature and short URL sub-feature privilege
### should be granted for both `All` and `Read`.
subFeatures.privileges:
download_csv_report.disabled: true
url_create:
disabled: true
includeIn: "read"
### Maps feature is disabled since it's automatically granted by Dashboard feature.
maps.disabled: true
```
## How to test
Log in as the `admin` using SAML and navigate to the `Custom roles`
management section to edit role and see tuned role management UX:
<p align="center">
<img
src="ad6e4b07-53bd-4f5a-ae91-66d6534c711a"
/>
<img
src="8ab4d5a3-f719-42d5-a278-3aee87603c33"
/>
</p>
### Search project
```bash
yarn es serverless --projectType=es --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=es --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.es.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-search` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="5088320b-3cc8-4de9-984c-d70fc6277659"
/>
</p>
### Observability project
```bash
yarn es serverless --projectType=oblt --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=oblt --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.oblt.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-o11y` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="110572b1-f08a-4427-a687-5c2e0240a36b"
/>
</p>
### Security project
```bash
yarn es serverless --projectType=security --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=security --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.security.yml` in this PR to see the specific changes
made for your project type:
Create a custom `custom-security` role and re-login as the user with
this role to test your project type (you need to manually type role name
if the role selector):
<p align="center">
<img
src="2bec6ae2-8d19-4142-a479-9a81bc1fca14"
/>
</p>
__Fixes: https://github.com/elastic/kibana/issues/178963__
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Per [the OAS docs](https://swagger.io/specification/), they have an info
object with a `summary` and `description` field. This PR refactors the
existing router `description` field to to OAS `summary` (that is how it
has been used) and introduces a "new" `description` field that will be
used for the longer form descriptions.
## Resources
* https://swagger.io/specification/
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: lcawl <lcawley@elastic.co>
Part of https://github.com/elastic/kibana-team/issues/769
## Summary
This PR adds a "created by" filter to the dashboard listing page. We've
added the created_by field recently
[here](https://github.com/elastic/kibana/pull/179344) so only newly
created by interactive users dashboards will be populated with
`created_by`
### Demo
<img width="1510" alt="Screenshot 2024-04-25 at 16 32 03"
src="ac70ffea-05be-4d70-bbfa-c1cc9d5dd747">
<img width="1510" alt="Screenshot 2024-04-25 at 16 32 11"
src="9889ccae-08d0-4fb6-977e-c42e85337e0e">
### Implementation notes
#### Suggesting users
We suggest only the users that have at least one dashboard. We do this
by aggregating dashboard saved objects by `created_by`. Because we don't
have server-side pagination or sorting yet, in this initial version, I
decided to do this client-side to keep it as simple as possible for now.
Initially, I did this server-side inside a dashboard plugin as an
internal API route. In the long term, this should probably be moved to
content management in some form, but it is not clear how it should look
yet. This is the commit where I reverted and moved it to client-side
06316ee8f2
#### Clint side filtering
The user filter is simply a client-side filter because we anyway
currently have an in-memory table with client-side sorting and
pagination. There is no much practical value in server-side filter atm
The filter allows to filter-in by multiple users. It also allows to
filter items without creators
#### `created_by` filter isn't part of the query string
I introduced a separate state for this filter, similar to `tableSort`
and `pagination`. The reason why the `created_by` filter isn't a part of
the `searchQuery` is because we use `profile_id` which looks ugly for
the user, e.g. `u_mGBROF_q5bmFCATLXAcCwKa0k8JvONAwSruelyKA5E_0` so we
can't just add it to a user-facing search query like we do with tags.
`profile_id` is the correct identified we should use, `username` might
not be enough in some cases + `username` in cloud is unreadble account
number. The best alternative could be email, but it isn't always
available. This is why I decided to keep the `created_by` filter hidden
from the user behind the user picker popover and not expose it to the
search bar. The `created_by` filter is synced into the URL just like the
rest of the table state.
#### No distinguishing the current user
There is no logic in place that somehow highlights or renames the
current user in the filter. This can be added, but to limit the scope of
the MVP I didn't do it.
#### User filter component
We use the `UsersProfilePopover` provided by the security team. We use
it without any overrides, so the component decides how to show users in
a popover. I noticed a small visual issue with an email truncation in a
smaller popover. Might be worth a separate issue.
### Testing
1. Create multiple new users
2. Login for each of them
3. Created a dashboard for each of them
4. Play with the filter
#### Next Steps
The next step would be to add a column with the user:
Closes https://github.com/elastic/kibana/issues/164104
## Summary
**Replace "Download CSV" with "Generate CSV report" to export a CSV file
from saved search panel, deprecate "Download CSV", use a config flag for
providing the deprecated feature.**
This PR uses the `xpack.reporting.csv.enablePanelActionDownload`
kibana.yml setting, which was previously unused, for choosing behavior
of CSV export in a Dashboard saved search panel, and sets the default
value to `false`. The options allow the user to download a CSV file
without creating a report (deprecated, support will be removed in the
future) or to generate a CSV report (default).
1. Use the config as a flag to switch between implementations:
- downloading a CSV file without a generated report
- generating a CSV report
2. Updated documentation
3. Refactored / cleaned up tests
4. Increased API test coverage in Serverless
5. Better error handling in
`packages/kbn-reporting/public/reporting_api_client.ts`
### Checklist
Delete any items that are not applicable to this PR.
- [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]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
## Release Note
Kibana CSV Reporting offered a feature allowing users to download a CSV
file from a saved search panel in a dashboard, without having a report
generated. This feature is now deprecated. Now, when users need to
access saved search data from a dashboard panel as CSV, a normal report
will be generated. To access the deprecated functionality, you can add
`xpack.reporting.csv.enablePanelActionDownload: true` to kibana.yml, but
this ability will be removed in a future version of Kibana.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
fix https://github.com/elastic/kibana/issues/163842
Currently, Saved Objects Management Kibana privilege ( either read or
all) is needed in order for a user to see custom branding. Without it,
users with custom roles see the default branding after logging in.
Custom branding is stored in the new "global" advanced settings
("config-global" saved object). Only users with Saved Objects Management
privilege had access to it. This PR adds "config-global" to the list of
automatically applied privileges similar to "config".
## Summary
This PR is updating Discover's rule to be created under the
`stackAlerts` consumer and we created an [breaking change
issue](https://github.com/elastic/dev/issues/2344) to explain the
consequences of this update.
We also fix the rule's consumer for all rule types created under the
observability rule management to use their producer instead of `alerts`.
Also, we add the ability for the ES Query and new Generic Threshold
rules type to pick the consumer associated to the rule. The
`ensureAuthorized` and the `filter` functions have modified and
simplified to support this use case please check the newest unit test
added in
`x-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts`.
There is now a dropdown in the rule form to prompt the user when
creating ES Query/Generic threshold rules to select the consumer based
on their authorized consumers (we can no longer use `alerts` for these).
If there is only 1 option, then the dropdown will not be shown and the
option will be chosen automatically.
Generic threshold rules will have the following possible consumers:
- infrastructure
- logs
ES query rules will have the following possible consumers:
- infrastructure
- logs
- stackAlerts (only from the stack management rule page)
## To Test:
### Single Consumer:
1. Create a user with only `logs` feature enabled (ensuring
`stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. Assert that the rule created has `logs` set in the `consumer` field
7. Repeat 5-6 for the generic threshold rule
8. Repeat 2-7 but on the Stack Management rules page
9. Repeat 1-8 for the `infrastructure` feature.
### Multiple Consumers:
1. Create a user with `logs`, `infrastructure` and `apm` features
enabled (ensuring `stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. A dropdown should prompt the user to select between 1 of the 3
consumers, select 1
7. Assert that the rule was created with the selected consumer
8. Repeat 5-7 for the generic threshold rule
9. Repeat 2-8 but on the Stack Management rules 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: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR cleans up some outstanding tech debt.
### 1. Remove deprecation warning for `disabled` prop
This property was marked as deprecated the moment it was introduced (See
https://github.com/elastic/kibana/pull/118001/files#r753124740). However
it has been adopted by Fleet and Guided Onboarding plugins so I don't
think there's value in keeping this deprecation warning in place.
As an alternative we could also bump the `@removeBy` version if people
think we should still remove this property.
### ~~2. Remove deprecated property `requiredRoles`~~
~~This property has been deprecated and marked for removal for 8.8. The
property isn't being used anywhere in our codebase and we have reached
feature freeze for 8.8 so looks safe to be removed now.~~
Turns out this property is still used and can't be removed without
breaking existing functionality so reverting that commit.
## Summary
The spread operator is costly and put pressure on GC. It should be
avoided when possible, especially in loops.
This PR adapts a lot of `reduce` calls in the codebase to remove the
usages of the diabolic spread operator, when possible.
Note: the PR is not fully exhaustive. I focused on the server-side, as
we're more directly impacted than on browser-side code regarding
performances.
## Removing `...` usages in `kittens.reduce()`
For `reduce` loops, the spread operator can usually easily be replaced:
#### - setting a value on the accum object and returning it
#### BAD
```ts
return this.toArray().reduce(
(acc, renderer) => ({
...acc,
[renderer.name]: renderer,
}),
{} as Record<string, ExpressionRenderer>
);
```
#### GOOD
```ts
return this.toArray().reduce((acc, renderer) => {
acc[renderer.name] = renderer;
return acc;
}, {} as Record<string, ExpressionRenderer>);
```
#### - assigning values to the accum object and returning it
#### BAD
```ts
const allAggs: Record<string, any> = fieldAggRequests.reduce(
(aggs: Record<string, any>, fieldAggRequest: unknown | null) => {
return fieldAggRequest ? { ...aggs, ...(fieldAggRequest as Record<string, any>) } : aggs;
},
{}
);
```
#### GOOD
```ts
const allAggs = fieldAggRequests.reduce<Record<string, any>>(
(aggs: Record<string, any>, fieldAggRequest: unknown | null) => {
if (fieldAggRequest) {
Object.assign(aggs, fieldAggRequest);
}
return aggs;
},
{}
);
```
#### - pushing items to the accum list and returning it
#### BAD
```ts
const charsFound = charToArray.reduce(
(acc, char) => (value.includes(char) ? [...acc, char] : acc),
[] as string[]
);
```
#### GOOD
```ts
const charsFound = charToArray.reduce((acc, char) => {
if (value.includes(char)) {
acc.push(char);
}
return acc;
}, [] as string[]);
```
## Questions
#### Are you sure all the changes in this are strictly better for
runtime performances?
Yes, yes I am.
#### How much better?
Likely not much.
#### Are you planning on analyzing the perf gain?
Nope.
#### So why did you do it?
I got tired of seeing badly used spread operators in my team's owned
code, and I had some extra time during on-week, so I spent a few hours
adapting the usages in all our runtime/production codebase.
#### Was it fun?
Take your best guess.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.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>
## 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>
## Summary
Introduce a default file kind for images in Kibana. This file kind will
be the download/upload target usable for all images across Kibana.
Consider the following:
A Kibana user wants to add a branding logo to their dashboard. They need
to create a new image or select from a set of existing images (i.e.,
images already uploaded). This set of images is the "default image" set.
The idea will be this set of images can be access across dashboards and
solutions. For example, the same user can access the branding image they
uploaded in Cases.
## How it works
* We added a new default file kind specifically for images, this is
registered from the files plugin
* In order to access these files over HTTP users will need the
`files:defaultImage` privilege
* This is a distinct privilege from the file management privilege and
allows users to access HTTP endpoints controlled by
`access:files:defaultImage` as well as the underlying `file` saved
object
* Consider a dashboard user that wants to add an image embeddable: they
will need access to `file` saved object as well as the endpoints for
creating/reading/deleting the default file kind. In order to get this
their role must grant the new "Shared images" privilege.
<img width="749" alt="Screenshot 2022-11-22 at 10 34 25"
src="https://user-images.githubusercontent.com/8155004/203295230-24a0be94-9c59-4a53-8757-336e9fc8f6c4.png">
## Summary
Files management UI that rounds out the files MVP. This is UI is
intended to be progressively enhanced and provides a way for system
administrators get some insight and manage the files created and stored
in Kibana.
## To reviewers
* This is UI for retrieval and deletion of files (the R+D of CRUD)
* Creating and deleting tags to be supported in a future version
* This UI is intended to form part of the broader content management
experience
* We use the `TableListView` component as far as possible
## How to test
1. Start Kibana with `yarn start --run-examples`
2. Go to the "Developer Examples" from the left nav menu
3. Go to the "Files example" plugin
4. Click the "Upload file" button, upload a few different image types
(PNG, JPG and WEBP)
5. Go to "Stack management" > "Files"
6. Behold your files in the management UI
7. (Bonus) check that the UI and API `GET /api/files/find`, `GET
/api/files/metrics` and `DELETE /api/files/blobs` are not accessible to
non-admin or appropriately privileged users (i.e., those with "Files
management" access).
## List of functionality
- [x] List all saved objects (scoped to admin)
- [x] Is able to bulk-delete files
- [x] Shows basic storage diagnostics
- [x] Is able to search and filter files
## Screenshots
<details>
<summary>screenshots</summary>
<img width="1545" alt="Screenshot 2022-11-08 at 13 56 54"
src="https://user-images.githubusercontent.com/8155004/200570783-cfefdbf3-c5ff-4ece-ba24-48a455fcca75.png">
<img width="910" alt="Screenshot 2022-11-10 at 12 52 35"
src="https://user-images.githubusercontent.com/8155004/201083812-bc9f25f5-b423-43a6-9229-5e2a4cdd943a.png">
<img width="451" alt="Screenshot 2022-11-10 at 12 37 07"
src="https://user-images.githubusercontent.com/8155004/201081039-832a1980-684c-4abb-bb05-0c7c6a849d4d.png">
<img width="959" alt="Screenshot 2022-11-08 at 13 57 15"
src="https://user-images.githubusercontent.com/8155004/200570797-f122cff5-7043-4e01-9b51-d5663c1b26d6.png">
<img width="500" alt="Screenshot 2022-11-08 at 13 57 38"
src="https://user-images.githubusercontent.com/8155004/200570801-35cdbd99-0256-4dee-9f78-2f6ad853305f.png">
</details>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* Adds requireAllSpaces flag for subfeatures.
* fixes ts errors
* Adds unit test on sub features form UI
* Adds unit test for validateKibanaPrivileges function with subfeatures
* Fixes failing tests
* Rename some vars and reorder return null. Also skip two tests that are not working as expected
* Reorder if condition for performance optimisation
* Fixes unit test
* PR feedback - remove useMemo and use a function
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Splitting out cases privs
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* Getting tests working
* Fixing import error
* Fixing tests
* Fixing role to only have delete permissions
* Extracting sub feature tests to trial license
* Removing deletion user from common tests
* Addressing feedback
* Fixing tests
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
* set min license level to gold
* remove use of standard license
* update tests to check for gold level license
* accept gold license in feature registration
* Revert "remove use of standard license"
This reverts commit 684f8f500c.
* refactor LICENSE_TYPE_STANDARD to LICENSE_TYPE_CLOUD_STANDARD
* also update canvas to use gold min
* updated canvas features snapshot
* remember to save files!
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Remove timelion app and stuff which related to it
* Fix CI
* Fix lint
* Fix tests
* Fix tests
* Fis tests
* Fix some comments
* Clean up
* fix CI
* fix some comments
* Fix deprecation examples
* Return `enabled` property in config for timelion vis
* Remove unused angular lib
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alexey Antonov <alexwizp@gmail.com>
* Make indexPattern only read only in Discover permission
* Fix test failures
* Address review comments
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* [build_ts_refs] improve caches, allow building a subset of projects
* cleanup project def script and update refs in type check script
* rename browser_bazel config to avoid kebab-case
* remove execInProjects() helper
* list references for tsconfig.types.json for api-extractor workload
* disable composite features of tsconfig.types.json for api-extractor
* set declaration: true to avoid weird debug error
* fix jest tests
Co-authored-by: spalger <spalger@users.noreply.github.com>
* [ML] Update file data visualizer permissions
* adding home bundle
* fixing translations
* removing home from bundles
* switching to current user for analysis
* adding find structure permission check
* clean up
* updating text
* updating maps
* removing has_find_file_structure_permission endpoint
* removing more code
* adding permission error message
* renaming variable
* adding fileUpload:analyzeFile back into ML
* updating error text
* updating snapshots
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Adding feature flag for auth
* Hiding SOs and adding consumer field
* First pass at adding security changes
* Consumer as the app's plugin ID
* Create addConsumerToSO migration helper
* Fix mapping's SO consumer
* Add test for CasesActions
* Declare hidden types on SO client
* Restructure integration tests
* Init spaces_only integration tests
* Implementing the cases security string
* Adding security plugin tests for cases
* Rough concept for authorization class
* Adding comments
* Fix merge
* Get requiredPrivileges for classes
* Check privillages
* Ensure that all classes are available
* Success if hasAllRequested is true
* Failure if hasAllRequested is false
* Adding schema updates for feature plugin
* Seperate basic from trial
* Enable SIR on integration tests
* Starting the plumbing for authorization in plugin
* Unit tests working
* Move find route logic to case client
* Create integration test helper functions
* Adding auth to create call
* Create getClassFilter helper
* Add class attribute to find request
* Create getFindAuthorizationFilter
* Ensure savedObject is authorized in find method
* Include fields for authorization
* Combine authorization filter with cases & subcases filter
* Fix isAuthorized flag
* Fix merge issue
* Create/delete spaces & users before and after tests
* Add more user and roles
* [Cases] Convert filters from strings to KueryNode (#95288)
* [Cases] RBAC: Rename class to scope (#95535)
* [Cases][RBAC] Rename scope to owner (#96035)
* [Cases] RBAC: Create & Find integration tests (#95511)
* [Cases] Cases client enchantment (#95923)
* [Cases] Authorization and Client Audit Logger (#95477)
* Starting audit logger
* Finishing auth audit logger
* Fixing tests and types
* Adding audit event creator
* Renaming class to scope
* Adding audit logger messages to create and find
* Adding comments and fixing import issue
* Fixing type errors
* Fixing tests and adding username to message
* Addressing PR feedback
* Removing unneccessary log and generating id
* Fixing module issue and remove expect.anything
* [Cases] Migrate sub cases routes to a client (#96461)
* Adding sub cases client
* Move sub case routes to case client
* Throw when attempting to access the sub cases client
* Fixing throw and removing user ans soclients
* [Cases] RBAC: Migrate routes' unit tests to integration tests (#96374)
Co-authored-by: Jonathan Buttner <jonathan.buttner@elastic.co>
* [Cases] Move remaining HTTP functionality to client (#96507)
* Moving deletes and find for attachments
* Moving rest of comment apis
* Migrating configuration routes to client
* Finished moving routes, starting utils refactor
* Refactoring utilites and fixing integration tests
* Addressing PR feedback
* Fixing mocks and types
* Fixing integration tests
* Renaming status_stats
* Fixing test type errors
* Adding plugins to kibana.json
* Adding cases to required plugin
* [Cases] Refactoring authorization (#97483)
* Refactoring authorization
* Wrapping auth calls in helper for try catch
* Reverting name change
* Hardcoding the saved object types
* Switching ensure to owner array
* [Cases] Add authorization to configuration & cases routes (#97228)
* [Cases] Attachments RBAC (#97756)
* Starting rbac for comments
* Adding authorization to rest of comment apis
* Starting the comment rbac tests
* Fixing some of the rbac tests
* Adding some integration tests
* Starting patch tests
* Working tests for comments
* Working tests
* Fixing some tests
* Fixing type issues from pulling in master
* Fixing connector tests that only work in trial license
* Attempting to fix cypress
* Mock return of array for configure
* Fixing cypress test
* Cleaning up
* Addressing PR comments
* Reducing operations
* [Cases] Add RBAC to remaining Cases APIs (#98762)
* Starting rbac for comments
* Adding authorization to rest of comment apis
* Starting the comment rbac tests
* Fixing some of the rbac tests
* Adding some integration tests
* Starting patch tests
* Working tests for comments
* Working tests
* Fixing some tests
* Fixing type issues from pulling in master
* Fixing connector tests that only work in trial license
* Attempting to fix cypress
* Mock return of array for configure
* Fixing cypress test
* Cleaning up
* Working case update tests
* Addressing PR comments
* Reducing operations
* Working rbac push case tests
* Starting stats apis
* Working status tests
* User action tests and fixing migration errors
* Fixing type errors
* including error in message
* Addressing pr feedback
* Fixing some type errors
* [Cases] Add space only tests (#99409)
* Starting spaces tests
* Finishing space only tests
* Refactoring createCaseWithConnector
* Fixing spelling
* Addressing PR feedback and creating alert tests
* Fixing mocks
* [Cases] Add security only tests (#99679)
* Starting spaces tests
* Finishing space only tests
* Refactoring createCaseWithConnector
* Fixing spelling
* Addressing PR feedback and creating alert tests
* Fixing mocks
* Starting security only tests
* Adding remainder security only tests
* Using helper objects
* Fixing type error for null space
* Renaming utility variables
* Refactoring users and roles for security only tests
* Adding sub feature
* [Cases] Cleaning up the services and TODOs (#99723)
* Cleaning up the service intialization
* Fixing type errors
* Adding comments for the api
* Working test for cases client
* Fix type error
* Adding generated docs
* Adding more docs and cleaning up types
* Cleaning up readme
* More clean up and links
* Changing some file names
* Renaming docs
* Integration tests for cases privs and fixes (#100038)
* [Cases] RBAC on UI (#99478)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Fixing case ids by alert id route call
* [Cases] Fixing UI feature permissions and adding UI tests (#100074)
* Integration tests for cases privs and fixes
* Fixing ui cases permissions and adding tests
* Adding test for collection failure and fixing jest
* Renaming variables
* Fixing type error
* Adding some comments
* Validate cases features
* Fix new schema
* Adding owner param for the status stats
* Fix get case status tests
* Adjusting permissions text and fixing status
* Address PR feedback
* Adding top level feature back
* Fixing feature privileges
* Renaming
* Removing uneeded else
* Fixing tests and adding cases merge tests
* [Cases][Security Solution] Basic license security solution API tests (#100925)
* Cleaning up the fixture plugins
* Adding basic feature test
* renaming to unsecuredSavedObjectsClient (#101215)
* [Cases] RBAC Refactoring audit logging (#100952)
* Refactoring audit logging
* Adding unit tests for authorization classes
* Addressing feedback and adding util tests
* return undefined on empty array
* fixing eslint
* [Cases] Cleaning up RBAC integration tests (#101324)
* Adding tests for space permissions
* Adding tests for testing a disable feature
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* WIP - creating alerting authorization client factory and exposing authorization client on plugin start contract
* Updating alerting feature privilege builder to handle different alerting types
* Passing in alerting authorization type to AlertingActions class string builder
* Passing in authorization type in each function call
* Passing in exempt consumer ids. Adding authorization type to audit logger
* Changing alertType to ruleType
* Changing alertType to ruleType
* Updating unit tests
* Updating unit tests
* Passing field names into authorization query builder. Adding kql/es dsl option
* Converting to es query if requested
* Fixing functional tests
* Removing ability to specify feature privilege name in constructor
* Fixing some types and tests
* Consolidating alerting authorization kuery filter options
* Cleanup and tests
* Cleanup and tests
* Initial commit with changes needed for subfeature privilege
* Throwing error when AlertingAuthorizationClientFactory is not defined
* Renaming authorizationType to entity
* Renaming AlertsAuthorization to AlertingAuthorization
* Fixing unit tests
* Changing schema of alerting feature privilege
* Changing schema of alerting feature privilege
* Updating feature privilege iterator
* Updating feature privilege builder
* Fixing types check
* Updating privilege string terminology
* Updating privilege string terminology
* Wip
* Fixing unit tests
* Unit tests
* Updating README and removing stack subfeature privilege changes
* Fixing README
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* add a link for issue to remove circular deps
* features: migrate from joi to config-schema
* update tests
* migrate home tutorials to config-schema
* migrate home dataset validation to config schema
* remove unnecessary type. we cannot guarantee this is a valid SO
* address Pierres comments
* Adding importableAndExportable but hidden saved object types to saved object feature privilege
* Adding helper function for transforming rule for export. Added audit logging
* Adding helper function for transforming rule for export. Added audit logging
* Adding unit test for transforming rules for export
* Exporting connectors
* Removing auditing during export
* Adding import/export to docs
* PR fixes
* Using action type validation onExport
* Fixing logic for connectors with optional secrets
* Fixing logic for connectors with optional secrets
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* add base config for all the TS projects
* all the project use new tsconfig.project.json
* compile test files in the high-level tsconfig.json
* fix TS error in maps plugin
* fix TS error in infra plugin
* exclude mote test and test until folders
* uptime. do not import test code within prod code
* expressions. do not import test code within prod code
* data: export mocks from high level folder
* task_manager: comply with es client typings
* infra: remove unused enzyme_helpers
* check_ts_project requires "include" key
* ts_check should handle parent configs
* all ts configs should extend base one
* exclude test folders from plugins
* update patterns to fix ts_check errors
* Apply suggestions from code review
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
* uptime: MountWithReduxProvider to test helpers
Co-authored-by: Constance <constancecchen@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
