mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
f635e2a3b0
## Summary This PR aims to answer questions about the implementation details for https://github.com/elastic/kibana-team/issues/1328 We'd like to trigger an intercept dialog to users at specific time intervals that vary and depend on different parameters, see the PRD linked in the aforementioned issue. This MVP takes an approach such that the constraints listed below are resolved; - Have the intercept be specific to a single user - Define a strategy to configure triggers that can vary for the intercept that's not dependent on the client How does this work? - A generic plugin has been created which when declared as dependency can be used to register and schedule an intercept that should be presented to the user, this plugin is what's been used for the product intercept dialog. - To handle rendering the UI component that gets displayed to the users, in this PR we hook into core's existing notification system, through the notification coordinator system that's been created so that we don't have a situation where an intercept is being displayed whilst a user might have a toast being rendered to them, if there's an intercept to be displayed said intercept would not be displayed till the user is completely done interacting with the toast. [See it's implementation details here](src/core/packages/notifications/browser-internal/src/notification_coordinator.ts) and [here](x-pack/platform/plugins/private/intercepts/public/prompter/service/intercept_dialog_service.tsx) for how it's integrated. - The plugin provides some bootstrap data through an endpoint that every user calls on page load, ideally this would need to happen just the once on page load, we then compute when a user should see a trigger leveraging the bootstrap data provided for the particular registered trigger in question, the returned data returns the following data as seen below; <img width="476" alt="Screenshot 2025-03-27 at 18 01 12" src="https://github.com/user-attachments/assets/c747b6c8-70d0-4305-b555-ec9998b180c1" /> Given we have this data we might then have a flow for triggering the intercept on the client based of the bootstrap data like so; ```mermaid flowchart TD A[State Bootstrap] --> B{Has data?} B -->|No| C(Do Nothing) B -->|Yes| D{Does computed runs since trigger registration match stored user trigger run feedback value?} D -->|No| E[setup timer to display an intercept in that time] E -->|on completion| G[setup interval to display intercept in the future] D -->|Yes| G G -->|repeat| G ``` reloading the page restarts the entire process. ## Telemetry The intercept component provided by defaults records telemetry for intercept registration, acknowledgement (differentiated into dismissal and completion), alongside registration overload. ## Visuals <!-- https://github.com/user-attachments/assets/b39a506c-a119-40e8-9152-258d78691f28 --> <!-- https://github.com/user-attachments/assets/f564b4bc-9ad9-4e19-8158-6e154ef52fc2 --> <img width="738" alt="Screenshot 2025-05-07 at 19 41 23" src="https://github.com/user-attachments/assets/902c6d0b-9299-44bd-8808-4ad97227d0da" /> ## Testing this PR - Pull this branch to your machine - Add the following to your `kibana.dev.yml`, to enable the intercept to run and be visible ```yml xpack.intercepts.enabled: true xpack.product_intercept.enabled: true xpack.product_intercept.interval: '30s' ``` <!-- ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] 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/src/platform/packages/shared/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] 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) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] [See some risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) - [ ] ... --> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| development/plugins/expressions/public | ||
| extend | ||
| reference | ||
| release-notes | ||
| settings-gen | ||
| CHANGELOG.asciidoc | ||
| docset.yml | ||