mirror of
https://github.com/elastic/kibana.git
synced 2025-07-03 05:33:38 -04:00
5 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Kibana Machine
|
6e12acb428
|
[8.x] Preparation for High Contrast Mode, Analytics Experience domains (#202608) (#204120)
# Backport This will backport the following commits from `main` to `8.x`: - [Preparation for High Contrast Mode, Analytics Experience domains (#202608)](https://github.com/elastic/kibana/pull/202608) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Tim Sullivan","email":"tsullivan@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-12-12T19:16:07Z","message":"Preparation for High Contrast Mode, Analytics Experience domains (#202608)\n\n## Summary\r\n\r\n**Reviewers: Please test the code paths affected by this PR. See the\r\n\"Risks\" section below.**\r\n\r\nPart of work for enabling \"high contrast mode\" in Kibana. See\r\nhttps://github.com/elastic/kibana/issues/176219.\r\n\r\n**Background:**\r\nKibana will soon have a user profile setting to allow users to enable\r\n\"high contrast mode.\" This setting will activate a flag with\r\n`<EuiProvider>` that causes EUI components to render with higher\r\ncontrast visual elements. Consumer plugins and packages need to be\r\nupdated selected places where `<EuiProvider>` is wrapped, to pass the\r\n`UserProfileService` service dependency from the CoreStart contract.\r\n\r\n**NOTE:** **EUI currently does not yet support the high-contrast mode\r\nflag**, but support for that is expected to come in around 2 weeks.\r\nThese first PRs are simply preparing the code by wiring up the\r\n`UserProvideService`.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\nReviewers should verify this PR satisfies this list as well.\r\n\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- [X] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_note:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n### Risks\r\n\r\nDoes this PR introduce any risks? For example, consider risks like hard\r\nto test bugs, performance regression, potential of data loss.\r\n\r\nDescribe the risk, its severity, and mitigation for each identified\r\nrisk. Invite stakeholders and evaluate how to proceed before merging.\r\n\r\n- [ ] [medium/high] The implementor of this change did not manually test\r\nthe affected code paths and relied on type-checking and functional tests\r\nto drive the changes. Code owners for this PR need to manually test the\r\naffected code paths.\r\n- [ ] [medium] The `UserProfileService` dependency comes from the\r\nCoreStart contract. If acquiring the service causes synchronous code to\r\nbecome asynchronous, check for race conditions or errors in rendering\r\nReact components. Code owners for this PR need to manually test the\r\naffected code paths.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"99aa884fa08beafd801588c0b38194ec03039008","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Presentation","Team:Visualizations","release_note:skip","v9.0.0","Team:DataDiscovery","backport:prev-minor","v8.18.0"],"title":"Preparation for High Contrast Mode, Analytics Experience domains","number":202608,"url":"https://github.com/elastic/kibana/pull/202608","mergeCommit":{"message":"Preparation for High Contrast Mode, Analytics Experience domains (#202608)\n\n## Summary\r\n\r\n**Reviewers: Please test the code paths affected by this PR. See the\r\n\"Risks\" section below.**\r\n\r\nPart of work for enabling \"high contrast mode\" in Kibana. See\r\nhttps://github.com/elastic/kibana/issues/176219.\r\n\r\n**Background:**\r\nKibana will soon have a user profile setting to allow users to enable\r\n\"high contrast mode.\" This setting will activate a flag with\r\n`<EuiProvider>` that causes EUI components to render with higher\r\ncontrast visual elements. Consumer plugins and packages need to be\r\nupdated selected places where `<EuiProvider>` is wrapped, to pass the\r\n`UserProfileService` service dependency from the CoreStart contract.\r\n\r\n**NOTE:** **EUI currently does not yet support the high-contrast mode\r\nflag**, but support for that is expected to come in around 2 weeks.\r\nThese first PRs are simply preparing the code by wiring up the\r\n`UserProvideService`.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\nReviewers should verify this PR satisfies this list as well.\r\n\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- [X] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_note:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n### Risks\r\n\r\nDoes this PR introduce any risks? For example, consider risks like hard\r\nto test bugs, performance regression, potential of data loss.\r\n\r\nDescribe the risk, its severity, and mitigation for each identified\r\nrisk. Invite stakeholders and evaluate how to proceed before merging.\r\n\r\n- [ ] [medium/high] The implementor of this change did not manually test\r\nthe affected code paths and relied on type-checking and functional tests\r\nto drive the changes. Code owners for this PR need to manually test the\r\naffected code paths.\r\n- [ ] [medium] The `UserProfileService` dependency comes from the\r\nCoreStart contract. If acquiring the service causes synchronous code to\r\nbecome asynchronous, check for race conditions or errors in rendering\r\nReact components. Code owners for this PR need to manually test the\r\naffected code paths.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"99aa884fa08beafd801588c0b38194ec03039008"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/202608","number":202608,"mergeCommit":{"message":"Preparation for High Contrast Mode, Analytics Experience domains (#202608)\n\n## Summary\r\n\r\n**Reviewers: Please test the code paths affected by this PR. See the\r\n\"Risks\" section below.**\r\n\r\nPart of work for enabling \"high contrast mode\" in Kibana. See\r\nhttps://github.com/elastic/kibana/issues/176219.\r\n\r\n**Background:**\r\nKibana will soon have a user profile setting to allow users to enable\r\n\"high contrast mode.\" This setting will activate a flag with\r\n`<EuiProvider>` that causes EUI components to render with higher\r\ncontrast visual elements. Consumer plugins and packages need to be\r\nupdated selected places where `<EuiProvider>` is wrapped, to pass the\r\n`UserProfileService` service dependency from the CoreStart contract.\r\n\r\n**NOTE:** **EUI currently does not yet support the high-contrast mode\r\nflag**, but support for that is expected to come in around 2 weeks.\r\nThese first PRs are simply preparing the code by wiring up the\r\n`UserProvideService`.\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following conditions. \r\n\r\nReviewers should verify this PR satisfies this list as well.\r\n\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- [X] The PR description includes the appropriate Release Notes section,\r\nand the correct `release_note:*` label is applied per the\r\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\r\n\r\n### Risks\r\n\r\nDoes this PR introduce any risks? For example, consider risks like hard\r\nto test bugs, performance regression, potential of data loss.\r\n\r\nDescribe the risk, its severity, and mitigation for each identified\r\nrisk. Invite stakeholders and evaluate how to proceed before merging.\r\n\r\n- [ ] [medium/high] The implementor of this change did not manually test\r\nthe affected code paths and relied on type-checking and functional tests\r\nto drive the changes. Code owners for this PR need to manually test the\r\naffected code paths.\r\n- [ ] [medium] The `UserProfileService` dependency comes from the\r\nCoreStart contract. If acquiring the service causes synchronous code to\r\nbecome asynchronous, check for race conditions or errors in rendering\r\nReact components. Code owners for this PR need to manually test the\r\naffected code paths.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"99aa884fa08beafd801588c0b38194ec03039008"}},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com> |
||
Gerard Soldevila
|
58c8aff91c
|
[8.x] Sustainable Kibana Architecture: Categorise straightforward packages (#199630) (#201340)
# Backport This will backport the following commits from `main` to `8.x`: - [Sustainable Kibana Architecture: Categorise `straightforward` packages (#199630)](https://github.com/elastic/kibana/pull/199630) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Gerard Soldevila","email":"gerard.soldevila@elastic.co"},"sourceCommit":{"committedDate":"2024-11-22T09:33:25Z","message":"Sustainable Kibana Architecture: Categorise `straightforward` packages (#199630)\n\n## Summary\r\n\r\nThis PR is part of the Kibana Sustainable Architecture effort.\r\n\r\nThe goal is to start categorising Kibana packages into _generic\r\nplatform_ (`group: \"platform\"`) vs _solution-specific_.\r\n\r\n```\r\ngroup?: 'search' | 'security' | 'observability' | 'platform'\r\nvisibility?: 'private' | 'shared'\r\n```\r\nUncategorised modules are considered to be `group: 'common', visibility:\r\n'shared'` by default.\r\n\r\nWe want to prevent code from solution A to depend on code from solution\r\nB.\r\nThus, the rules are pretty simple:\r\n\r\n* Modules can only depend on:\r\n * Modules in the same group\r\n * OR modules with 'shared' visibility\r\n* Modules in `'observability', 'security', 'search'` groups are\r\nmandatorily `visibility: \"private\"`.\r\n\r\nLong term, the goal is to re-organise packages into dedicated folders,\r\ne.g.:\r\n\r\n```\r\nx-pack/platform/plugins/private\r\nx-pack/observability/packages\r\n```\r\n\r\nFor this first wave, we have categorised packages that seem\r\n\"straightforward\":\r\n* Any packages that have:\r\n * at least one dependant module\r\n * all dependants belong to the same group\r\n* Categorise all Core packages:\r\n * `@kbn/core-...-internal` => _platform/private_\r\n * everything else => _platform/shared_\r\n* Categorise as _platform/shared_ those packages that:\r\n * Have at least one dependant in the _platform_ group.\r\n * Don't have any `devOnly: true` dependants.\r\n\r\n### What we ask from you, as CODEOWNERS of the _package manifests_, is\r\nthat you confirm that the categorisation is correct:\r\n\r\n* `group: \"platform\", visibility: \"private\"` if it's a package that\r\nshould only be used from platform code, not from any solution code. It\r\nwill be loaded systematically in all serverless flavors, but solution\r\nplugins and packages won't be able to `import` from it.\r\n* `group: \"platform\", visibility: \"shared\"` if it's a package that can\r\nbe consumed by both platform and solutions code. It will be loaded\r\nsystematically in all serverless flavors, and anybody can import / use\r\ncode from it.\r\n* `group: \"observability\" | \"security\" | \"search\", visibility:\r\n\"private\"` if it's a package that is intented to be used exclusively\r\nfrom a given solution. It won't be accessible nor loaded from other\r\nsolutions nor platform code.\r\n\r\nPlease refer to\r\n[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)\r\nfor any related questions.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"b24fdf5d3f6b7454a4edcedb8141b82f571e1d74","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","release_note:skip","v9.0.0","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-infra_services"],"number":199630,"url":"https://github.com/elastic/kibana/pull/199630","mergeCommit":{"message":"Sustainable Kibana Architecture: Categorise `straightforward` packages (#199630)\n\n## Summary\r\n\r\nThis PR is part of the Kibana Sustainable Architecture effort.\r\n\r\nThe goal is to start categorising Kibana packages into _generic\r\nplatform_ (`group: \"platform\"`) vs _solution-specific_.\r\n\r\n```\r\ngroup?: 'search' | 'security' | 'observability' | 'platform'\r\nvisibility?: 'private' | 'shared'\r\n```\r\nUncategorised modules are considered to be `group: 'common', visibility:\r\n'shared'` by default.\r\n\r\nWe want to prevent code from solution A to depend on code from solution\r\nB.\r\nThus, the rules are pretty simple:\r\n\r\n* Modules can only depend on:\r\n * Modules in the same group\r\n * OR modules with 'shared' visibility\r\n* Modules in `'observability', 'security', 'search'` groups are\r\nmandatorily `visibility: \"private\"`.\r\n\r\nLong term, the goal is to re-organise packages into dedicated folders,\r\ne.g.:\r\n\r\n```\r\nx-pack/platform/plugins/private\r\nx-pack/observability/packages\r\n```\r\n\r\nFor this first wave, we have categorised packages that seem\r\n\"straightforward\":\r\n* Any packages that have:\r\n * at least one dependant module\r\n * all dependants belong to the same group\r\n* Categorise all Core packages:\r\n * `@kbn/core-...-internal` => _platform/private_\r\n * everything else => _platform/shared_\r\n* Categorise as _platform/shared_ those packages that:\r\n * Have at least one dependant in the _platform_ group.\r\n * Don't have any `devOnly: true` dependants.\r\n\r\n### What we ask from you, as CODEOWNERS of the _package manifests_, is\r\nthat you confirm that the categorisation is correct:\r\n\r\n* `group: \"platform\", visibility: \"private\"` if it's a package that\r\nshould only be used from platform code, not from any solution code. It\r\nwill be loaded systematically in all serverless flavors, but solution\r\nplugins and packages won't be able to `import` from it.\r\n* `group: \"platform\", visibility: \"shared\"` if it's a package that can\r\nbe consumed by both platform and solutions code. It will be loaded\r\nsystematically in all serverless flavors, and anybody can import / use\r\ncode from it.\r\n* `group: \"observability\" | \"security\" | \"search\", visibility:\r\n\"private\"` if it's a package that is intented to be used exclusively\r\nfrom a given solution. It won't be accessible nor loaded from other\r\nsolutions nor platform code.\r\n\r\nPlease refer to\r\n[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)\r\nfor any related questions.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"b24fdf5d3f6b7454a4edcedb8141b82f571e1d74"}},"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/199630","number":199630,"mergeCommit":{"message":"Sustainable Kibana Architecture: Categorise `straightforward` packages (#199630)\n\n## Summary\r\n\r\nThis PR is part of the Kibana Sustainable Architecture effort.\r\n\r\nThe goal is to start categorising Kibana packages into _generic\r\nplatform_ (`group: \"platform\"`) vs _solution-specific_.\r\n\r\n```\r\ngroup?: 'search' | 'security' | 'observability' | 'platform'\r\nvisibility?: 'private' | 'shared'\r\n```\r\nUncategorised modules are considered to be `group: 'common', visibility:\r\n'shared'` by default.\r\n\r\nWe want to prevent code from solution A to depend on code from solution\r\nB.\r\nThus, the rules are pretty simple:\r\n\r\n* Modules can only depend on:\r\n * Modules in the same group\r\n * OR modules with 'shared' visibility\r\n* Modules in `'observability', 'security', 'search'` groups are\r\nmandatorily `visibility: \"private\"`.\r\n\r\nLong term, the goal is to re-organise packages into dedicated folders,\r\ne.g.:\r\n\r\n```\r\nx-pack/platform/plugins/private\r\nx-pack/observability/packages\r\n```\r\n\r\nFor this first wave, we have categorised packages that seem\r\n\"straightforward\":\r\n* Any packages that have:\r\n * at least one dependant module\r\n * all dependants belong to the same group\r\n* Categorise all Core packages:\r\n * `@kbn/core-...-internal` => _platform/private_\r\n * everything else => _platform/shared_\r\n* Categorise as _platform/shared_ those packages that:\r\n * Have at least one dependant in the _platform_ group.\r\n * Don't have any `devOnly: true` dependants.\r\n\r\n### What we ask from you, as CODEOWNERS of the _package manifests_, is\r\nthat you confirm that the categorisation is correct:\r\n\r\n* `group: \"platform\", visibility: \"private\"` if it's a package that\r\nshould only be used from platform code, not from any solution code. It\r\nwill be loaded systematically in all serverless flavors, but solution\r\nplugins and packages won't be able to `import` from it.\r\n* `group: \"platform\", visibility: \"shared\"` if it's a package that can\r\nbe consumed by both platform and solutions code. It will be loaded\r\nsystematically in all serverless flavors, and anybody can import / use\r\ncode from it.\r\n* `group: \"observability\" | \"security\" | \"search\", visibility:\r\n\"private\"` if it's a package that is intented to be used exclusively\r\nfrom a given solution. It won't be accessible nor loaded from other\r\nsolutions nor platform code.\r\n\r\nPlease refer to\r\n[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)\r\nfor any related questions.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"b24fdf5d3f6b7454a4edcedb8141b82f571e1d74"}}]}] BACKPORT--> |
||
Luke Elmers
|
b6287708f6
|
Adds AGPL 3.0 license (#192025)
Updates files outside of x-pack to be triple-licensed under Elastic License 2.0, AGPL 3.0, or SSPL 1.0. |
||
Sébastien Loix
|
9db8d2558c
|
[Core] Deprecate nav link status (#176383) | ||
Davis McPhee
|
3e1865513d
|
[Discover] Add resize support to the Discover field list sidebar (#167066)
## Summary
This PR adds resize support to the Discover field list sidebar, which is
persisted to a user's local storage similar to the resizable chart
height.
Additionally it migrates the resizable layout code from Unified
Histogram to a new package called `kbn-resizable-layout` so it can be
shared between Discover and Unified Histogram, as well as act as a new
platform component that other teams can consume to create their own
resizable layouts.
![resize](
|