feature:notifications
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
feature:notifications [2008/11/09 17:45] – erickson | feature:notifications [2008/11/09 17:50] – erickson | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== Notifications Infrastructure Proposal/ | ||
+ | * Date: 2008/11/07 | ||
+ | * Author: Bill Erickson | ||
+ | |||
+ | ==== Introduction ==== | ||
+ | |||
+ | The purpose of this document is to define how Evergreen components generate and manage notifications. | ||
+ | |||
+ | |||
+ | ==== Creating notices ==== | ||
+ | |||
+ | - Some positive event occurs. | ||
+ | - Context information is passed directly to a new class method OpenILS:: | ||
+ | * $context is a key/value set of data relevant to the notification. | ||
+ | * The handler for this type of event is the only code that needs to understand the content of $context. | ||
+ | * $context will be stored in the DB as a JSON object. | ||
+ | * $context should only contain object IDs, where necessary, and not full objects, since they will be re-retrieved at notice generation time, to ensure current data. | ||
+ | * Many notice types will not require any $context data. For example, "max fines reached" | ||
+ | - See if there already exists a like pending notification type in the database for this user. If so, stop there. | ||
+ | - Based on the type of event and user/ | ||
+ | - For each delivery mechanism, create a new row in the notification table (action.notification_queue? | ||
+ | # DB table | ||
+ | id | ||
+ | usr | ||
+ | create_time | ||
+ | notification_type | ||
+ | delivery_protocol | ||
+ | notify_time | ||
+ | # The big question, how do we manage delivery times? | ||
+ | # what else?</ | ||
+ | - CRON job, which regularly checks, picks up the next batch of notices whose delivery window coincides with " | ||
+ | - Each notice is passed to OpenILS:: | ||
+ | - If a handler has been registered for this event type, call the handler with the context data. The handler, using the "hold ready for pickup" | ||
+ | - Handler collects hold-related data from the DB to build a notification context object. | ||
+ | * The context object will be the same regardless of delivery protocol. | ||
+ | - Pass the context object to the delivery handler. | ||
+ | * This passes the context object through the appropriate notification template to generate the notice content | ||
+ | * Sends notice | ||
+ | |||
+ | ==== Canceling Notices ==== | ||
+ | |||
+ | - Negative event occurs. | ||
+ | - Context info (same as create-notice context) is passed to OpenILS:: | ||
+ | - context info is passed to the registered handler, which finds any like notifications in the DB and deletes/ | ||
+ | |||
+ | |||
+ | ==== Managing notification windows ==== | ||
+ | |||
+ | There are two main points to consider: | ||
+ | - Manditory pre-notify delay. | ||
+ | * For example, before sending a hold notification, | ||
+ | * This one seems relatively straightforward. | ||
+ | - Day/Time specific notification windows. | ||
+ | * For example, "I accept phone notifications weekdays, between 5pm and 7pm" | ||
+ | * **??** | ||
+ | |||
+ | ==== Managing Templates ==== | ||
+ | |||
+ | Ideally, templates would live in the database, however, that would require a template editor of some sort. For now, we may just want to leave them on the file system with org-unit settings that map to the relevant template file. | ||
+ | |||
+ | ==== Miscellaneous ==== | ||
+ | |||
+ | The open-ils.penalty server already understands max overdues and max fines. |
feature/notifications.txt · Last modified: 2022/02/10 13:34 by 127.0.0.1