admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2020-07-09 00:14:17 +00:00
parent 8ba32666b7
commit f1056844bb
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
devdocs/specs/core-notification.txt
View File

@@ -22,10 +22,10 @@ BACKEND TODO / SYSTEM FOR RAVEN
TODO: need a utility that can hash any adhoc collection of fields to work with various notify related objects TODO: need a utility that can hash any adhoc collection of fields to work with various notify related objects
TODO: Auto delete APP notifications older than 90 days automatically by some kind of sweeper job TODO: Never creates a duplicate APP or EMAIL notify, so checks a hash in history log before sending
TODO: auto delete notifyeventlog entries older than 90 days automatically by job TODO: HASH uniquely identifies a notification delivery and it's logged with the history so before a new delivery is sent it's compared to the delivery log and if it was sent
todo: in the last 90 days then it skips it. This will avoid duplicated emails or runaway notifies etc.
Hash needs to be unique to the destination user, teh source object and the event type exactly, if there is any difference then it should not hash the same
CREATING NOTIFICATIONS CREATING NOTIFICATIONS
OBJECTS Saving an object triggers notification processing for that object: OBJECTS Saving an object triggers notification processing for that object:
@@ -131,7 +131,7 @@ Notifyevent table - contains all events, created by updating objects or directly
created (timestamp used to clean out old stuck events), ayatype, objectid, eventtype, appliestouserid (single subscriber event), aEventDate, ASAVEDMESSAGE, HASH? created (timestamp used to clean out old stuck events), ayatype, objectid, eventtype, appliestouserid (single subscriber event), aEventDate, ASAVEDMESSAGE, HASH?
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 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 ) (aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID, HASH )
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 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 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