Patron Notices (UXPROD-18)

[UXPROD-2385] Improved logging related to patron notice processing Created: 20/Apr/20  Updated: 22/Feb/22  Resolved: 13/Sep/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Kiwi (R3 2021)
Parent: Patron Notices

Type: New Feature Priority: P2
Reporter: Darcy Branchini Assignee: Darcy Branchini
Resolution: Done Votes: 0
Labels: cap-mvp, error_handling, split, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-3574 Remove send errors in the circ, that ... Draft
is defined by CIRC-1157 [SPIKE] Find approach to capturing an... Closed
is defined by CIRC-1180 Capture all scheduled patron notice p... Closed
is defined by CIRC-1183 Capture all non-scheduled patron noti... Closed
is defined by CIRC-1195 Test logging of errors related to pro... Closed
is defined by MODFEE-200 Capture FOLIO system errors in FEE/FI... Closed
is defined by MODAUD-85 [SPIKE] Find approach to handling pat... Closed
is defined by MODAUD-86 Add support for NOTICE_ERROR log even... Closed
is defined by UICIRCLOG-70 Add support for log records with new ... Closed
Relates
relates to UXPROD-2698 Configure custom headers in mod-email Closed
relates to UXPROD-4685 create Jest/RTL test for RefundReason... Closed
relates to UXPROD-2157 Design ONLY - better error handling, ... Closed
relates to UXPROD-2382 Visual of system health for patron n... Closed
relates to UXPROD-2394 Improved logging of activities throug... Closed
relates to UXPROD-2384 Improved handling of send errors for ... Draft
Epic Link: Patron Notices
Back End Estimate: XXL < 30 days
Back End Estimator: Oleksandr Vidinieiev
Development Team: Vega
PO Rank: 70
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R1
Rank: hbz (TBD): R1
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

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 Draft 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 Closed 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 Closed )
  • Improved handling of errors for patron notices (i.e., recovery, retry sending) ( UXPROD-2384 Draft )
  • Improved logging related to patron notice processing (THIS FEATURE - UXPROD-2385 Closed )

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


Generated at Fri Feb 09 00:23:31 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.