You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
POST /api/v1/templates and DELETE /api/v1/templates/:templateName endpoints both produce a WebSocket notification on success (as well as indicating success by the HTTP status code in the response). However, neither of these produce a graphical notification in the web-client.
At face value this comes down to the NotificationChannel.service.tsx simply not subscribing to the stream of messages with this category. However, this would be a recurring problem with more event categories that are added - and may already be an issue with other categories than the two for Event Templates. There is already some logic in the Notifications.tsx for determining whether a WebSocket message indicates some kind of "action" event (response to a user-initiated or automated API request), a "problem" (some API request failed), reflects WebSocket client activity, or indicates that a target JVM (dis)appeared. Rather than the NotificationsChannel.service.tsx explicitly opting in to some set of categories for which to display notifications, perhaps it should listen to all incoming messages with all categories, and display notifications for all of the ones that are "actions".
The text was updated successfully, but these errors were encountered:
POST /api/v1/templates
andDELETE /api/v1/templates/:templateName
endpoints both produce a WebSocket notification on success (as well as indicating success by the HTTP status code in the response). However, neither of these produce a graphical notification in the web-client.At face value this comes down to the
NotificationChannel.service.tsx
simply not subscribing to the stream of messages with this category. However, this would be a recurring problem with more event categories that are added - and may already be an issue with other categories than the two for Event Templates. There is already some logic in theNotifications.tsx
for determining whether a WebSocket message indicates some kind of "action" event (response to a user-initiated or automated API request), a "problem" (some API request failed), reflects WebSocket client activity, or indicates that a target JVM (dis)appeared. Rather than theNotificationsChannel.service.tsx
explicitly opting in to some set of categories for which to display notifications, perhaps it should listen to all incoming messages with all categories, and display notifications for all of the ones that are "actions".The text was updated successfully, but these errors were encountered: