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 21:26:22 +00:00
parent 4e29788355
commit 217cc57a0a
3 changed files with 90 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -130,21 +130,21 @@ 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)
/notifysubscription table - contains all user (and customer user) 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, has user id
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, attachreportid, intags, outtags, HASH)
(aID, userId, ayatype, aEventType, advancenoticetimespan, idvalue, decvalue, 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
/Notifyevent table - contains all events, created by updating objects or directly in some cases and used by generator for processing as deliveries
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
(aRootObjectType, aRootObjectID, aEventType,aGuidValue, aDeliveryDate, aToUserID, aDeliveryMethod, aDelivered, aErrorMessage, aToClientID, HASH )
(ayatype, objectID, 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
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