devdocs/specs/core-notification.txt

@@ -17,6 +17,35 @@
 	their device email notification settings, not our concern anymore.
 	
 
+###########################################################
+BACKEND TODO / SYSTEM FOR RAVEN
+
+CREATING NOTIFICATIONS
+OBJECTS Saving an object triggers notification processing for that object:
+	- in v7 biz object just submits any possible notification and later it's checked to see if anyone subscribes
+		would be better to short circuit that at the biz object to stop if no events of interest
+	- type and id is submitted to eventofinterest checker (possibly also tags I think)
+		AyaType, ID, eventlist,objectbefore,objectafter
+		eventofinterest db table contains each type and event id
+			some types are generic and apply to all corebiz for example
+				i.e. tags used on an object or added
+		but a workorder object would be best suited to check if a workorder is interesting event?
+		monolithic class for all notifications goes through a giant switch?
+	- HASH to prevent dupes
+		hash all the relevant bits of a notification that make it unique then check the db table to see if that hash exists already, this is a fast way to prevent dupes
+			should notify if this happens a lot maybe?
+		Post delivery maybe keep a hash of the event notified on so it doesn't re-notify the exact same thing repeatedly after it was already sent
+
+
+
+
+
+
+
+
+
+
+###########################################################
 
 
 Important cases:
@@ -30,7 +59,7 @@ ALL EVENT TYPES INITIAL RELEASE
 
 ## OLD
 WorkOrderStatusChange [GENERAL]
-ContractExiring (User notify, add more notify before time frames in cases) [GENERAL]
+ContractExpiring (User notify, add more notify before time frames in cases) [GENERAL]
 CSRAccepted [CUSTOMER]
 CSRRejected [CUSTOMER]
 NewWorkorder [CUSTOMER]