Improved logging related to patron notice processing

In scope This feature adds errors to the circulation log that arise within mod-circulation and mod-feesfines while processing notices. This includes both scheduled and non-scheduled notices. See the descriptions on this technical documentation to better understand the overall process.

Out of scope Errors that happen within mod-notify, mod-sender, mod-email. See UXPROD-3201 for that featuer.

UPDATE 7/2/2021: In reviewing and addressing a task assigned to Vega due to a bug reported that there was inconsistent entries between logging on the BE (email_statistics table) and logging on the FE (circulation log)), Vega discovered that it was relatively easy to add failure errors that happen within certain modules, i.e., mod-circulation and/or mod-feefine, whereas it's more difficult to add errors happening within mod-notify, mod-sender and mod-email. For the short term, CIRC-1157 will address errors that happen within mod-circulation and mod-feefine by capturing them and reporting them to the mod-audit and the post them on the circ-log (FE). This feature addresses the lower level processing and errors happening within one of those modules.

UPDATE 4/9/2021: Developers have reported more recently that it's been slowly improved over time as well as the overall notice system is more stable than when this feature was proposed. It might not be required anymore or it might not be as urgent.

Problem: There are many steps in processing emails for patron notices, including: 1.) matching notice policies to location, material type, loan type and patron group using circulation rules; 2.) building emails from templates for each patron; 3.) retrieving data from FOLIO; 4.) running when scheduled, if applicable; and 5.) sending to email service/server. An error might occur at any of those steps or the SMTP credentials might be incorrect or a bug or another issue might interfere with the processing of patron notices. Library staff need to know if notices are not being processed. Ideally they'd prefer to have visibility of errors or problems, but also successful statistics (i.e., how many were sent overnight).

Description: In early discussions about this feature, we've identified options and/or steps that improve this visibility of both successful and problematic processing of notices with information about which step failed.

• Visual of system health for patron notices (i.e., dashboard with go/no-go status for each module/component) (UXPROD-2382)
• Improved handling of errors for patron notices (i.e., recovery, retry sending) (UXPROD-2384)
• Improved logging related to patron notice processing (THIS FEATURE - UXPROD-2385)

SPLIT: This feature is being split (April 2020) for each of these steps/options.