## Summary
Address #166459
This PR scaffolds telemetry into the notification service, to enable
reporting when deduped toasts are dismissed. When a deduped toast is
dismissed; the message recurrence count and the toast message would be
emitted.
Telemetry Event Definition;
```typescript
{
eventType: "global_toast_list_toast_dismissed",
schema: {
"toast_deduplication_count": {
type: "long",
_meta: {
description: "toast message text"
}
},
"toast_message": {
type: "keyword",
_meta: {
description: "recurrence count for particular toast message"
}
},
"toast_message_type": {
type: "keyword",
_meta: {
description: "toast message type, accepted values are warning, danger, primary"
}
}
}
}
```
Testing;
- Ensure you have an existing dashboard, if you don't installing any
sample data would bootstrap a dashboard automatically
- Search for `visualize library` from the global search bar, and
navigate to visualize library.
- Attempt to create a visualization, select the `TSVB` visualization
type. At this step there typically wouldn't be an error
- We can simulate an error, by open Dev tools and blocking the URL
`/internal/metrics/vis/data` like so <img width="604" alt="Screenshot
2023-09-21 at 11 49 41"
src="ad320569-33b2-4335-8052-981d1761ea67">
on doing this, we then attempt refreshing the query, we would then be
presented with an error toast, similar to the screenshot below;
<img width="482" alt="Screenshot 2023-09-21 at 11 52 51"
src="fef07e72-625b-4457-abc3-9214d64f9e48">
click the refresh query button as much as you like to increase it's
recurrence count.
- From here on we verify that; clicking the dismiss button sends a
telemetry event, also not interacting with the toast and it's display
lifetime elapsing with the toast clearing itself, the telemetry gets
sent still. In either case there should be a request calling the
resource `kibana_browser` with a payload containing the telemetry event
definition above.
### Checklist
<!-- Delete any items that are not applicable to this PR. -->
- [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
<!-- - [ ] Any UI touched in this PR is usable by keyboard only (learn
more about [keyboard
accessibility](https://webaim.org/techniques/keyboard/))
- [ ] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [ ] 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 renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ->
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
ec20d615de