88 lines
3.2 KiB
Plaintext
88 lines
3.2 KiB
Plaintext
# Notification specifications
|
|
|
|
Important cases:
|
|
client viewing ui (was popup in v7) https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3783
|
|
|
|
|
|
ALL EVENT TYPES INITIAL RELEASE
|
|
================================
|
|
OLD
|
|
|
|
|
|
NEW
|
|
Daily_Notify_health_check (biz and ops)
|
|
Nightly_Notify_health_check (biz and ops)
|
|
BackupStatus case 3786 (biz and ops)
|
|
UpcomingServiceEvent case 3725 (Customer)
|
|
|
|
|
|
|
|
|
|
|
|
SCRATCHPAD IDEAS
|
|
=-=-=-=-=-=-=-=-=-
|
|
|
|
OVERVIEW
|
|
General
|
|
thinking of reforming it, making all notifications very short since user can go to directly view data online anyway now, why have an overly time consuming system to format and shit
|
|
i.e. no notification more than an SMS (160 characters but will accept more and split them up to 1600) tweet in length (280 characters)
|
|
|
|
In cases where user wants to send an attachment / report / wiki that's another thing entirely but the message is still super short
|
|
|
|
|
|
UI
|
|
Subscribe from the object itself's menu rather than centralized subscription setup (new)
|
|
Admin can still subscribe users on their behalf (new)
|
|
|
|
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
|
|
No delivery schedule anymore, let user decide how to handle at their device end, not our concern, just deliver immediately always
|
|
|
|
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??)
|
|
- 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
|
|
- Create a notification event in a table of pending notification events [CENTRAL_NOTIFICATION_CLASS]
|
|
- See v7 schema for ideas
|
|
|
|
Deliver notifications
|
|
- Job triggers and HandleJob is called on [CENTRAL_NOTIFICATION_CLASS] which in turn checks if any events ready to Deliver
|
|
- Hands off NOTIFY_EVENT to deliver one at a time to a [NOTIFICATION_DELIVERY_CLASS] which in turn calls each [NOTIFICATION_DELIVERY_DELIVERY_TYPE-SMPT/POPUP/WHATEVER]
|
|
|
|
|
|
Maintenance
|
|
- [CoreJobNotificationSweeper class] maintains the notifications tables see generator spec for thoughts
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MISC
|
|
=-=-
|
|
|
|
- NOTIFICATION SUBSCRIPTIONS
|
|
- NOTIFICATION DELIVERIES (user or all if manager account)
|
|
|
|
- What is "Slack"?
|
|
- should we tie into it for notifications? |