Process non real-time patron notices

Purpose:
To create patron notice processor to process and send non real-time notices within system idle time, which will vary from institution to institution, but commonly between 1 am and 7 am. (TBD, start time and end time should be configured in mod-configuration)

Description:

• There are three types of notices in FOLIO: user-initiated, time-based and a change in status.
• Time-based notices could be real-time (higher priority, minimum delay to process and send) or non real-time and sent in batch or bulk. Batch emails are not lower priority, however, it is not important that they are sent immediately when a triggering event happens. As long as the entire batch scheduled for a particular night are all sent, it would be considered successful.
• This story is about non real-time notices only.
• Main idea is to process portions of non real-time notices within idle time (at night).
• Processor is the same as for real-time messages, the only difference is run interval and predefined "idle window" for notice processing.
• Performance testing is a must.

User Stories:

• As an administrator, I'd like to determine which notices need to be sent in real-time versus as a batch overnight (or during idle time) so that we can save on system resources during peak usage hours, which typically align with a libraries' open hours. Examples include: courtesy (or reminder) and overdue notices on long-term loans (not hourly loans), awaiting pick reminder, hold shelf expiration and request expiration. Supporting stories follow:
  • As an administrator, I'd like to schedule first reminder email notices 5 days before a long term loaned item becomes due so that patrons receive notification via email about their borrowed item and it's impending due date.
  • As an administrator, I'd like to schedule second and third reminder email notices 3 days (and again 1 day) before a long term loaned item becomes due so that patrons receive notification via email about their borrowed item and it's impending due date. Each notice will contain increasingly urgent language.
  • As an administrator, I'd like to schedule first overdue email notices 1 day after a long term loaned item becomes due so that patrons receive notification via email about their overdue item and any fee/fine accrual.
• As an administrator, I'd like to be able to schedule the time when non real-time notices can be sent so that I can schedule it at a time when the system is idle and when I know other batch processes are not maxing out the system.
• As an administrator, I'd like to send a single notice with multiple items, meeting certain time period threshold, so that less notices are ultimately needed and sent, which saves system resources, but will not be as annoying to a patron. Example is that a borrower might have 300 items all due at (or around the same time, might be within a few minutes or seconds of each other), it is preferred that they receive a single notice with mention of all 300 items.
• As a librarian, I'd like to know that any scheduled batch email notices were sent in a timely manner so that I be confident that the patrons I interact with received the notifications I expected them to receive.

User Stories - Chalmers:

• As an administrator, I'd like to send overdue notices daily, in bulk and scheduled (7 am in current system).
• As an administrator, I'd like to send upwards of 3,000 overdue notices in a single batch.
• As an administrator, I'd also like to send recall and awaiting pickup notices in real-time.
  • If overdue notices had to be sent in real-time, this would be acceptable for an interim solution as long as FOLIO's notice processing could handle it from a performance perspective. Note that Chalmers uses rolling loans (30-day, 60-day, etc.) and they have approximately 3800 open/active loans right now (7/1/2019), with a peak of almost 6000 in late April. Presumably the due dates are spread out; however, if someone checks out a book at 1:20:46 and someone else at 4:33:15 on the same day with a 30-day loan, their items are both due at 23:59:59 (not 1:20:46 and 4:33:15 respectively) 30 days later, so several notices will be queued to be sent at the same time each day.