From 28eb2dd4b64630da9c67e70ccf4bc43db2f269dc Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Thu, 14 May 2020 22:37:35 +0000 Subject: [PATCH] --- devdocs/specs/core-notification.txt | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/devdocs/specs/core-notification.txt b/devdocs/specs/core-notification.txt index 0f88906f..11018ddf 100644 --- a/devdocs/specs/core-notification.txt +++ b/devdocs/specs/core-notification.txt @@ -7,7 +7,15 @@ client viewing ui (was popup in v7) https://rockfish.ayanova.com/default.htm#!/r ALL EVENT TYPES INITIAL RELEASE ================================ OLD - +WorkOrderStatusChange +ContractExiring (User notify, add more notify before time frames in cases) +CSRAccepted (Customer) +CSRRejected (Customer) +NewWorkorder (customer) +WorkorderStatusChange (customer) +WorkorderClosed (customer) +WorkorderFollowUp (customer) +QuoteStatusChanged (customer) NEW Daily_Notify_health_check (biz and ops) @@ -15,11 +23,17 @@ Nightly_Notify_health_check (biz and ops) BackupStatus case 3786 (biz and ops) UpcomingServiceEvent case 3725 (Customer) WorkorderItemPartRequestCreated case 3652 +ContractExpiring - Customer version in addition to User version +Not for certain but in the hopper to think about: +On demand ad-hoc notification case 3466 for specific object only + not sure how to handle that, but it's a very intruiging idea, maybe it's a v.next one though? + or maybe the tags thing will handle this? - +CUSTOMER NOTIFICATIONS AND CHANGES +A bcc field for all customer notification subscriptions per case 3398 SCRATCHPAD IDEAS =-=-=-=-=-=-=-=-=- @@ -43,6 +57,7 @@ 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 +Notify BEfore shoudl support multiple time frames, not just one DELIVERY TYPES Email