177 lines
7.5 KiB
Plaintext
177 lines
7.5 KiB
Plaintext
# Notification specifications
|
|
|
|
|
|
|
|
|
|
############### LAST STATE OF THIS 2020-05-15 12:56:44:
|
|
Had gone over cases and triaged them, not super fleshed out yet how it works behind the scenes but basically
|
|
same as v7, object save triggers notification check which puts items into and takes them out of notify event table
|
|
recurring job processes them
|
|
Ideally would like to see event of interest check with cached data but need to consider how many different things would be in that, could be huge
|
|
since I will be adding so many new notification types and they are more complex.
|
|
|
|
client end is a list type form also each object can notify directly on demand and all users have default notification subscription
|
|
|
|
No longer templating but rather using short single text string with link back to open instead and optionally send report / attachment or whatever
|
|
also no delivery days or hours fuckery anymore, all deliveries happen all the time as appropriate to the event deliver date. If user wants that they can configure
|
|
their device email notification settings, not our concern anymore.
|
|
|
|
|
|
|
|
|
|
Important cases:
|
|
client viewing ui (was popup in v7) https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3783
|
|
|
|
|
|
|
|
ALL EVENT TYPES INITIAL RELEASE
|
|
================================
|
|
|
|
|
|
## OLD
|
|
WorkOrderStatusChange [GENERAL]
|
|
ContractExiring (User notify, add more notify before time frames in cases) [GENERAL]
|
|
CSRAccepted [CUSTOMER]
|
|
CSRRejected [CUSTOMER]
|
|
NewWorkorder [CUSTOMER]
|
|
WorkorderStatusChange [CUSTOMER]
|
|
WorkorderClosed [CUSTOMER]
|
|
WorkorderFollowUp [CUSTOMER]
|
|
QuoteStatusChanged [CUSTOMER]
|
|
ServiceBank[Currency/Hours/Incidents]Depleted [GENERAL]
|
|
NewCSR [GENERAL]
|
|
NewMemo [PERSONAL]
|
|
QuickNotification DEPRECATED replaced by DefaultNotification below [PERSONAL]
|
|
QuoteCreatedUpdated - a bit weird, which is it created or updated? :) [GENERAL]
|
|
ScheduleMarkerImminent (will rename) [PERSONAL]
|
|
ScheduleMarkerCreated (will rename) [PERSONAL]
|
|
WorkorderItemScheduledUserCreatedUpdated [PERSONAL]
|
|
WorkorderItemScheduledUserEventImminent [PERSONAL]
|
|
WorkorderCloseByDatePassed (user) [general]
|
|
WorkorderStatusChanged (user) [GENERAL]
|
|
WorkorderItemOutsideServiceOverdue [general]
|
|
WorkorderItemOutsideServiceReceivedBack [GENERAL]
|
|
WorkorderItemPartRequestPartsReceived [GENERAL]
|
|
|
|
|
|
## NEW
|
|
Daily_Notify_health_check (biz and ops) [GENERAL]
|
|
Nightly_Notify_health_check (biz and ops)[GENERAL]
|
|
BackupStatus case 3786 (biz and ops) [GENERAL]
|
|
(OR is this more of a general OPERATIONS notifications without choosing specific type because anyone in ops needs all)
|
|
UpcomingServiceEvent case 3725 [CUSTOMER]
|
|
WorkorderItemPartRequestCreated case 3652 [GENERAL]
|
|
ContractExpiring - Customer version in addition to User version [CUSTOMER]
|
|
WorkorderTotalExceedsThreshold - Custom notification case 1745 "the andy" [GENERAL]
|
|
WorkOrderStatusAge "deadman" delivery if not changed before XX time period [GENERAL]
|
|
|
|
QuoteStatusAge [PERSONAL (prepared by), GENERAL]
|
|
UnitWarranyExpiry case 1361 [GENERAL]
|
|
UnitMeterReadingMultipleExceeded case 1254 [GENERAL]
|
|
DefaultNotification case 3792 used for all system and old Quick notifications [EVERYONE]
|
|
TagNotification case 3799
|
|
|
|
PERSONAL? OR COVERED BY TAG FILTER ALREADY BETTER?
|
|
WorkorderItemPartRequestPartsReceivedWhenIAmScheduled [PERSONAL]
|
|
WorkorderItemOutsideServiceReceivedBackWhenIAmScheduled
|
|
WorkorderItemOutsideServiceOverdueWhenIAmScheduled
|
|
WorkorderCloseByDatePassedWhenIAmScheduled
|
|
WorkorderStatusChangedWhenIAmScheduled [PERSONAL]
|
|
|
|
|
|
Not for certain but in the hopper to think about:
|
|
On demand ad-hoc notification case 3466 for specific object only
|
|
not sure how to handle that, but it's a very intruiging idea, maybe it's a v.next one though?
|
|
or maybe the tags thing will handle this?
|
|
|
|
|
|
CUSTOMER NOTIFICATIONS AND CHANGES
|
|
A bcc field for all customer notification subscriptions per case 3398
|
|
|
|
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
|
|
|
|
All notifications can be optionally filtered IN or OUT via tags on notification related object. I.E. a workorder status change can be ignored or only see if it's tagged "region-new-york" etc
|
|
|
|
All users can receive general notifications which come from both the system itself and from other users using the new ad-hoc send notification from any form
|
|
|
|
UI
|
|
Subscribe from the object itself's menu rather than centralized subscription setup (new)
|
|
Admin can still subscribe users on their behalf (new)
|
|
|
|
SYSTEM
|
|
-=-=-=-=-=-=-=-=-=-
|
|
EVENT_OF_INTEREST_CLASS
|
|
|
|
Internal workings:
|
|
|
|
Should cache the event of interest for quick saving processing and save db getting hammered every time an object is saved
|
|
|
|
|
|
|
|
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
|
|
Notify BEfore shoudl support multiple time frames, not just one
|
|
Users not involved should not be notified, have choice on that`
|
|
e.g. if a user is not booked on a workorder and is just a lowly tech they don't care about other workorder status changes
|
|
|
|
|
|
Types of notifications sitting in delivery queue:
|
|
Deliver if something not changed before date "DEADMAN SWITCH"
|
|
upon change that negates it from source object it removes the event as no longer required
|
|
Deliver immediately regardless
|
|
easy peasy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- What is "Slack"?
|
|
- should we tie into it for notifications? |