This commit is contained in:
2020-05-14 20:09:29 +00:00
parent 3bf12913d6
commit c1852f48f9

View File

@@ -1,13 +1,40 @@
# Notification specifications
Important cases:
client viewing ui (was popup in v7) https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3783
SCRATCHPAD IDEAS
=-=-=-=-=-=-=-=-=-
OVERVIEW
Vast room for improvement over v7 which was byzantine and complicated
Process to set up new notification on workorder status changed:
Go to user page, click on notification subscription, click on NEW, select type of notification and additional info, click on save, select or add delivery method
Notification system
-=-=-=-=-=-=-=-=-=-
Internal workings:
One enum list of NotificationType for any possible notification that can be processed
Notify type is divided by actual type and then by actual delivery method
DELIVERY TYPES
Email
UI
(previusly was ayanova memo, but, that's toast now, removing it)
DELIVERY FORMAT
Custom templates for each notification set up centrally?
Hypothetical sequence of operations for designing raven notification and tie into jobs and processor
WidgetStatusChange notification
- OnChange event triggered in [WIDGETBIZ] with before and after state of widget in question (immediately after save or delete or whatever is of interest)
- OnChange processor See if any users are subscribed to this event [CENTRAL_NOTIFICATION_CLASS THIS MUST BE SUPER EFFICIENT AS IT WILL BE HAMMERED] (events of interest / core central event bus handler of some kind??)
- OnChange processor See if any users are subscribed to this event [CENTRAL_NOTIFICATION_CLASS THIS MUST BE SUPER EFFICIENT AS IT WILL BE HAMMERED]
(events of interest / core central event bus handler of some kind??)
- CENTRAL_NOTIFICATION_CLASS event of interest should cache in memory events of interest and trigger cache invalidation by [EVENT_OF_INTEREST_CLASS] subscription change
- If no then bail out early
- If yes then compares the before and after state of the widget and the given list of events of interest and processes notifications in turn