[OneDiscover][Extension] Allow providing custom ad-hoc data views #201669
Assignees
Labels
enhancement
New value added to drive a business result
Feature:Discover
Discover Application
impact:medium
Addressing this issue will have a medium level of impact on the quality/strength of our product.
Project:OneDiscover
Enrich Discover with contextual awareness
Team:DataDiscovery
Discover, search (e.g. data plugin and KQL), data views, saved searches. For ES|QL, use Team:ES|QL.
Comments
kertal
changed the title
kertal
added
the
Team:DataDiscovery
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
kertal
added
Project:OneDiscover
Merged
7 tasks
davismcphee
added a commit
that referenced
this issue
Jan 29, 2025
…Observability Solution view (#205991) (#208792) # Backport This will backport the following commits from `main` to `8.x`: - [[Discover] Add a default "All logs" temporary data view in the Observability Solution view (#205991)](#205991) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Davis McPhee","email":"davis.mcphee@elastic.co"},"sourceCommit":{"committedDate":"2025-01-29T15:04:32Z","message":"[Discover] Add a default \"All logs\" temporary data view in the Observability Solution view (#205991)\n\n## Summary\r\n\r\nThis PR adds an \"All logs\" ad hoc (temporary) data view to the Discover\r\nObservability root profile based on the central log sources setting,\r\nallowing quick access to logs (with the most up to date log sources)\r\nwithout needing to first manually create a data view:\r\n\r\n\r\nTo support this, a new `getDefaultAdHocDataViews` extension point has\r\nbeen added to Discover, allowing profiles to specify an array of ad hoc\r\ndata view specs would should be created by default when the profile is\r\nresolved, and automatically cleaned up when the profile changes or the\r\nuser leaves Discover.\r\n\r\nResolves #201669.\r\nResolves #189166.\r\n\r\n### Notes\r\n\r\n- The \"All logs\" ad hoc data view should only appear when using the\r\nObservability Solution view (in any deployment type).\r\n- Data view specs returned from `getDefaultAdHocDataViews` must include\r\nconsistent IDs across resolutions in order for Discover to manage them\r\ncorrectly (e.g. to find and reload the data view after a page refresh).\r\nSituations where we'd expect a change in ID (e.g. when saving to a\r\nDiscover session) are handled internally by Discover.\r\n- To avoid a breaking change, the returned ad hoc data views have no\r\nimpact on the default data view shown when navigating to Discover. If\r\nany persisted data views exist, one of them will be used as the default.\r\nIf no persisted data views exist, the first entry of the array returned\r\nby `getDefaultAdHocDataViews` will be used as the default.\r\n- We still want to notify users in Discover when they have no ES data at\r\nall, and prompt them to install integrations. For this reason, the \"no\r\ndata\" page is still shown in Discover even if there are default profile\r\nad hoc data views (unlike if there are persisted data views, in which\r\ncase we use the default and hide the \"no data\" page).\r\n- When saving a Discover session that uses a default profile ad hoc data\r\nview, the data view will be copied on save as `{DATA_VIEW_NAME} (copy)`.\r\nThis allows us to assign a unique ID to the version that gets saved with\r\nthe Discover session, and avoids having to choose between the profile\r\ndata view or the embedded data view when reopening the session, which\r\nhas drawbacks:\r\n- If choosing the profile data view, the Discover session may display\r\nincorrectly if the log sources setting changed since it was saved, and\r\nthe user would no longer be able to view the session as it was intended\r\nwithout first modifying the setting to the expected value.\r\n- If choosing the embedded data view, the replacement shown after\r\nopening the Discover session may not reflect the latest log sources\r\nsetting until a new session is started, and there would be no way for\r\nthe user to migrate the session to use the latest version of the profile\r\ndata view.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\r\n- [ ]\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- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [ ] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [x] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\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)","sha":"bf9d34465eaf49738b215cdcadfadb29c4c6188c","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","v9.0.0","Team:DataDiscovery","backport:prev-minor","Team:obs-ux-logs","Project:OneDiscover"],"title":"[Discover] Add a default \"All logs\" temporary data view in the Observability Solution view","number":205991,"url":"https://github.com/elastic/kibana/pull/205991","mergeCommit":{"message":"[Discover] Add a default \"All logs\" temporary data view in the Observability Solution view (#205991)\n\n## Summary\r\n\r\nThis PR adds an \"All logs\" ad hoc (temporary) data view to the Discover\r\nObservability root profile based on the central log sources setting,\r\nallowing quick access to logs (with the most up to date log sources)\r\nwithout needing to first manually create a data view:\r\n\r\n\r\nTo support this, a new `getDefaultAdHocDataViews` extension point has\r\nbeen added to Discover, allowing profiles to specify an array of ad hoc\r\ndata view specs would should be created by default when the profile is\r\nresolved, and automatically cleaned up when the profile changes or the\r\nuser leaves Discover.\r\n\r\nResolves #201669.\r\nResolves #189166.\r\n\r\n### Notes\r\n\r\n- The \"All logs\" ad hoc data view should only appear when using the\r\nObservability Solution view (in any deployment type).\r\n- Data view specs returned from `getDefaultAdHocDataViews` must include\r\nconsistent IDs across resolutions in order for Discover to manage them\r\ncorrectly (e.g. to find and reload the data view after a page refresh).\r\nSituations where we'd expect a change in ID (e.g. when saving to a\r\nDiscover session) are handled internally by Discover.\r\n- To avoid a breaking change, the returned ad hoc data views have no\r\nimpact on the default data view shown when navigating to Discover. If\r\nany persisted data views exist, one of them will be used as the default.\r\nIf no persisted data views exist, the first entry of the array returned\r\nby `getDefaultAdHocDataViews` will be used as the default.\r\n- We still want to notify users in Discover when they have no ES data at\r\nall, and prompt them to install integrations. For this reason, the \"no\r\ndata\" page is still shown in Discover even if there are default profile\r\nad hoc data views (unlike if there are persisted data views, in which\r\ncase we use the default and hide the \"no data\" page).\r\n- When saving a Discover session that uses a default profile ad hoc data\r\nview, the data view will be copied on save as `{DATA_VIEW_NAME} (copy)`.\r\nThis allows us to assign a unique ID to the version that gets saved with\r\nthe Discover session, and avoids having to choose between the profile\r\ndata view or the embedded data view when reopening the session, which\r\nhas drawbacks:\r\n- If choosing the profile data view, the Discover session may display\r\nincorrectly if the log sources setting changed since it was saved, and\r\nthe user would no longer be able to view the session as it was intended\r\nwithout first modifying the setting to the expected value.\r\n- If choosing the embedded data view, the replacement shown after\r\nopening the Discover session may not reflect the latest log sources\r\nsetting until a new session is started, and there would be no way for\r\nthe user to migrate the session to use the latest version of the profile\r\ndata view.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\r\n- [ ]\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- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [ ] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [x] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\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)","sha":"bf9d34465eaf49738b215cdcadfadb29c4c6188c"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/205991","number":205991,"mergeCommit":{"message":"[Discover] Add a default \"All logs\" temporary data view in the Observability Solution view (#205991)\n\n## Summary\r\n\r\nThis PR adds an \"All logs\" ad hoc (temporary) data view to the Discover\r\nObservability root profile based on the central log sources setting,\r\nallowing quick access to logs (with the most up to date log sources)\r\nwithout needing to first manually create a data view:\r\n\r\n\r\nTo support this, a new `getDefaultAdHocDataViews` extension point has\r\nbeen added to Discover, allowing profiles to specify an array of ad hoc\r\ndata view specs would should be created by default when the profile is\r\nresolved, and automatically cleaned up when the profile changes or the\r\nuser leaves Discover.\r\n\r\nResolves #201669.\r\nResolves #189166.\r\n\r\n### Notes\r\n\r\n- The \"All logs\" ad hoc data view should only appear when using the\r\nObservability Solution view (in any deployment type).\r\n- Data view specs returned from `getDefaultAdHocDataViews` must include\r\nconsistent IDs across resolutions in order for Discover to manage them\r\ncorrectly (e.g. to find and reload the data view after a page refresh).\r\nSituations where we'd expect a change in ID (e.g. when saving to a\r\nDiscover session) are handled internally by Discover.\r\n- To avoid a breaking change, the returned ad hoc data views have no\r\nimpact on the default data view shown when navigating to Discover. If\r\nany persisted data views exist, one of them will be used as the default.\r\nIf no persisted data views exist, the first entry of the array returned\r\nby `getDefaultAdHocDataViews` will be used as the default.\r\n- We still want to notify users in Discover when they have no ES data at\r\nall, and prompt them to install integrations. For this reason, the \"no\r\ndata\" page is still shown in Discover even if there are default profile\r\nad hoc data views (unlike if there are persisted data views, in which\r\ncase we use the default and hide the \"no data\" page).\r\n- When saving a Discover session that uses a default profile ad hoc data\r\nview, the data view will be copied on save as `{DATA_VIEW_NAME} (copy)`.\r\nThis allows us to assign a unique ID to the version that gets saved with\r\nthe Discover session, and avoids having to choose between the profile\r\ndata view or the embedded data view when reopening the session, which\r\nhas drawbacks:\r\n- If choosing the profile data view, the Discover session may display\r\nincorrectly if the log sources setting changed since it was saved, and\r\nthe user would no longer be able to view the session as it was intended\r\nwithout first modifying the setting to the expected value.\r\n- If choosing the embedded data view, the replacement shown after\r\nopening the Discover session may not reflect the latest log sources\r\nsetting until a new session is started, and there would be no way for\r\nthe user to migrate the session to use the latest version of the profile\r\ndata view.\r\n\r\n### Checklist\r\n\r\n- [x] Any text added follows [EUI's writing\r\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\r\nsentence case text and includes [i18n\r\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\r\n- [ ]\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- [ ] If a plugin configuration key changed, check if it needs to be\r\nallowlisted in the cloud and added to the [docker\r\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\r\n- [ ] This was checked for breaking HTTP API changes, and any breaking\r\nchanges have been approved by the breaking-change committee. The\r\n`release_note:breaking` label should be applied in these situations.\r\n- [x] [Flaky Test\r\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was\r\nused on any tests changed\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)","sha":"bf9d34465eaf49738b215cdcadfadb29c4c6188c"}}]}] BACKPORT-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
📓 Summary:
The contextual awareness framework in Discover should allow providing a custom set of ad-hoc data views in a given context. These ad-hoc dataviews should be selectable in the Data view picker
Note: ideally those ad-hoc data view should have a static id, to make sure shared links are not broken, this is not a functional requirement, but should be noted for consumers.
✔️Acceptance criteria:
The text was updated successfully, but these errors were encountered: