devdocs/specs/core-notification.txt

@@ -21,7 +21,7 @@
 BACKEND TODO / SYSTEM FOR RAVEN
 
 
-TODO: Get all potential CONDITIONS so know what needed beyond the old aGuidValue
+TODO: need a utility that can hash any adhoc collection of fields to work with various notify related objects
 TODO: client and user notify together so any changes required to support that need to be sussed out here as much as possible in advance
 
 CREATING NOTIFICATIONS
@@ -86,20 +86,57 @@ v7 - NotifyPopup contains UI deliveries
 	aNotifyPopUp (aID, aRootObjectType, aRootObjectID, aDeliveryDate, aToUserID,  aMessage ) 
 
 
-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
+V8 TABLES / OBJECTS
+ALL COREBIZ
+	Need CRUD check for notification events
+	Need to handle check of new tags vs existing tags (delta of tags) for any notification type
+	Need central common code just like biz rules check that processes notifications upon any changes
+		asks notifysubscription code which notifications to process
+			subscriptions code has either cached or on db lookup to see all that apply, returns an array of notifyeventtypes to be processed
+		Processes each notifyeventtype that it handles or passes off to central one maybe in some cases if common code
+
+NotifyEventType enum
+	A collection of every possibly notification event
+
+NotifyDeliveryMethod enum
+	SMTP, INAPP  (more in future)
+
+NotifySubscriptionBiz 
+	handles checking for subscription relevancy and returning to biz object caller what types of notify events to process
+	handles CRUD and biz rules for notifysubscriptions
+
+NotifyEventBiz
+	handles CRUD for notify events, called statically from all over the place
+	puts events in the table, removes them, updates them
+	Has no part in delivery except maybe to provide list to delivery object
+	
+NotificationBiz
+	handles CRUD for (app) Notification items displayed to user in app UI
+	handles flagging as seen and deleting etc
+
+NotifyDeliveryBiz
+	handle delivery and logging to notifydeliverylog
+	called by generator periodically
+
+MailMessageDelivery
+	Maybe a separate object to abstract deliving emails
+
+
+notifysubscription table - contains all user (and customer) 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
 	note use of subscriberid (0=all of type, or specific ID) and type, this would normally be type user and the user id but covers also the case of setting up a subscription for *ALL* customers (type customer id =0 meaning all)
 	also ayatype GLOBAL means that the subscription applies to events of any corebiz type 
 		so for example a CreatedWithTag notification or UpdatedWithTag notification will work on any object with that tag if global or a specific type i.e. customer with that tag
 	Then they can control by tag as well, intags are used to filter and include (or any if no intags), outtags filter out and trump intags
 		These are also used for tag type conditions
-	(aID, subscriberId, subscriberAyaType, ayatype, aEventType, advancenoticetimespan, aGuidValue, aDeliveryMethod, deliveryaddress, intags, outtags, HASH) 
-Notifyevent - contains all events, created by updating objects or directly in some cases and used by generator for processing as deliveries
+	(aID, subscriberId, subscriberAyaType, ayatype, aEventType, advancenoticetimespan, aGuidValue, aDeliveryMethod, deliveryaddress, attachreportid, intags, outtags, HASH) 
+
+Notifyevent table - contains all events, created by updating objects or directly in some cases and used by generator for processing as deliveries
 	ayatype, objectid, eventtype, appliestouserid (single subscriber event), aEventDate, ASAVEDMESSAGE, HASH?
-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
+
+notifydeliverylog table - intended for troubleshooting, logs deliveries with a cap on how many records it retains.  Keeping this as a separate and distinct OPS ui thing
 	(aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID )
 
-notification - was popup, now the ones that show in the APP type notify delivery in the UI list; has fields for opening source and reading message and indicating read
+notification table - was popup, now the ones that show in the APP type notify delivery in the UI list; has fields for opening source and reading message and indicating read
 	Note: deliberately no delivery date, if it's in this table it's delivered to user, advancenotice and genprocess handle whether it's in this table or not
 	eventtype should generally be enough for message but the "message" field contains any extra info
 	COLUMNS: id, userid, ayatype, objectid, eventtype (for message in ui), message