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