Patron Notices (UXPROD-18)

[UXPROD-2384] Improved handling of send errors for patron notices (i.e., recovery, retry sending) Created: 20/Apr/20  Updated: 14/Aug/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Patron Notices

Type: New Feature Priority: P2
Reporter: Darcy Branchini Assignee: julie.bickle
Resolution: Unresolved Votes: 0
Labels: cap-mvp, error_handling, notice_error, patron_notice, split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
is defined by MODSENDER-14 Patron notice email failures | FOLIO ... Closed
Relates
relates to UXPROD-2385 Improved logging related to patron no... 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
Epic Link: Patron Notices
Front-End Confidence factor: Medium
Back End Estimate: Large < 10 days
Back End Estimator: Darcy Branchini
Development Team: Volaris
PO Rank: 65
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R4
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R2
Rank: hbz (TBD): R2
Rank: Lehigh (MVP Summer 2020): R2
Rank: MO State (MVP June 2020): R2
Rank: U of AL (MVP Oct 2020): R2

 Description   

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.) running when scheduled; and 4.) 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 a 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 Won't do)
  • Improved handling of errors for patron notices (i.e., recovery, retry sending) (THIS FEATURE - UXPROD-2384 Draft )
  • Improved logging elated to patron notice processing ( UXPROD-2385 Closed )

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



 Comments   
Comment by julie.bickle [ 08/Dec/21 ]

Closing this feature because the related work has indeed been completed.

Comment by julie.bickle [ 17/Feb/22 ]

Reopened, because actually MODSENDER-14 was not completed, but "Won't do".

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