From 88d04f1354558f497cddb56b87fc389f3ac61a2e Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Thu, 14 May 2020 20:37:38 +0000 Subject: [PATCH] --- devdocs/specs/core-notification.txt | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/devdocs/specs/core-notification.txt b/devdocs/specs/core-notification.txt index 44df6e1e..f8990aa0 100644 --- a/devdocs/specs/core-notification.txt +++ b/devdocs/specs/core-notification.txt @@ -6,10 +6,14 @@ client viewing ui (was popup in v7) https://rockfish.ayanova.com/default.htm#!/r ALL EVENT TYPES INITIAL RELEASE ================================ +OLD + + +NEW Daily_Notify_health_check (biz and ops) Nightly_Notify_health_check (biz and ops) -BackupProcessed (biz and ops) - +BackupStatus case 3786 (biz and ops) +UpcomingServiceEvent case 3725 (Customer) @@ -26,17 +30,16 @@ General In cases where user wants to send an attachment / report / wiki that's another thing entirely but the message is still super short -ui - Vast room for improvement over v7 which was byzantine and complicated - Process to set up new notification on workorder status changed: - Go to user page, click on notification subscription, click on NEW, select type of notification and additional info, click on save, select or add delivery method +UI +Subscribe from the object itself's menu rather than centralized subscription setup (new) +Admin can still subscribe users on their behalf (new) -Notification system +SYSTEM -=-=-=-=-=-=-=-=-=- Internal workings: One enum list of NotificationType for any possible notification that can be processed Notify type is divided by actual type and then by actual delivery method - +No delivery schedule anymore, let user decide how to handle at their device end, not our concern, just deliver immediately always DELIVERY TYPES Email @@ -47,7 +50,6 @@ DELIVERY FORMAT - Hypothetical sequence of operations for designing raven notification and tie into jobs and processor WidgetStatusChange notification