From 754aecedb18b199180dbb2990f68f45b1009e561 Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Wed, 8 Jul 2020 19:12:39 +0000 Subject: [PATCH] --- devdocs/specs/core-notification.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/devdocs/specs/core-notification.txt b/devdocs/specs/core-notification.txt index 18d3d012..6897f91a 100644 --- a/devdocs/specs/core-notification.txt +++ b/devdocs/specs/core-notification.txt @@ -66,15 +66,15 @@ v8 (timespan can be a single value, no need for units and shit in the db, just d v7 - logs deliveries, removes any older than 7 days (that's short!?) aNotifyDeliveryLog (aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID ) -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 + (aID, aUserID, ayatype, aEventType, advancenoticetimespan, aGuidValue, aDeliveryMethod, deliveryaddress) Notifyevent - 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 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 - + (aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID ) ###########################################################