devdocs/specs/core-notification.txt

@@ -35,10 +35,21 @@ OBJECTS Saving an object triggers notification processing for that object:
 		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
+	- SUBSCRIPTION
+		User's indicate subscription with record in subscription table
+			Table has one row PER delivery method they want, default is APP type delivery meaning inside application
+			SMTP is alternative and will deliver via email to email account or phone sms etc
+			FUTURE may have alternatives here
+			DUPES are ignored 
+		This table is consulted for all decisions about notifications, no more eventofinterest separate table nor subscriber
+	- DELIVERY METHODS
+		no more date ranges for delivery windows
+		Two methods initially
+			SMTP
+			APP (meaning in notifications system inside application basically the old POPUP)
 
 
-
-TABLES
+TABLES WORKSHEET
 v7
 aNotifyEventOfInterest - subscribercount, ayatype, eventtype, "guidvalue" (extra info),created/creator/updated/updater
 v8 
@@ -48,7 +59,8 @@ v7 this is the main table where events are stored and delivered from (saved mess
 anotifyevent - ayatype, objectid, eventtype, appliestouserid (single subscriber event), aEventDate, ASAVEDMESSAGE
 
 v7 all subscriptions - used to process deliveries (checks for generic event to see who subscribes to it)
-anotifysubscription - ayatype, eventtype, userid, guidvalue
+anotifysubscription - aNotifySubscription (aID, aUserID, aRootObjectType, aEventType, aPendingSpan, aPendingSpanUnit, aGuidValue, aCreated, aModified, aCreator,aModifier) 
+v8 (timespan can be a single value, no need for units and shit in the db, just days or whatever the smallest unit is)
 
 
 v7 - logs deliveries, removes any older than 7 days (that's short!?)
@@ -58,6 +70,10 @@ QUESTIONS ABOUT v7 / improvements
 Why the anotifyeventofinterest table?
 	The subscription table already contains all that info, seems like an extra step plus it has to keep a tally of subscribers which seems prone to issues
 
+V8 TABLES
+notifysubscription - contains all users subscriptions to events and delivery method, if user wants two delivery methods they have two entries here, no other table indicates events to be tracked
+Notifyevent - contains all events, created by updating objects or directly in some cases and used by generator for processing as deliveries
+notifydeliverylog - intended for troubleshooting, logs deliveries with a cap on how many records it retains.  Keeping this as a separate and distinct OPS ui thing
 
 
 ###########################################################
@@ -203,7 +219,7 @@ WidgetStatusChange notification
 
 Deliver notifications
 	- Job triggers and HandleJob is called on [CENTRAL_NOTIFICATION_CLASS] which in turn checks if any events ready to Deliver
-		- Hands off NOTIFY_EVENT to deliver one at a time to a [NOTIFICATION_DELIVERY_CLASS] which in turn calls each [NOTIFICATION_DELIVERY_DELIVERY_TYPE-SMPT/POPUP/WHATEVER]
+		- Hands off NOTIFY_EVENT to deliver one at a time to a [NOTIFICATION_DELIVERY_CLASS] which in turn calls each [NOTIFICATION_DELIVERY_DELIVERY_TYPE-SMTP/POPUP/WHATEVER]
 
 
 Maintenance