Patron Notices (UXPROD-18)

[UXPROD-2157] Design ONLY - better error handling, logging, monitoring, displaying, and notifying FOLIO admins of patron notice issues and send stats Created: 15/Nov/19  Updated: 16/Sep/20  Resolved: 23/Jun/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q2 2020
Parent: Patron Notices

Type: New Feature Priority: P2
Reporter: Darcy Branchini Assignee: Darcy Branchini
Resolution: Won't Do Votes: 0
Labels: cap-mvp, split
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to MODNOTIFY-68 Update patron notice docs for DB sche... Closed
relates to UXPROD-2382 Visual of system health for patron n... Closed
relates to UXPROD-2385 Improved logging related to patron no... Closed
relates to UXPROD-2394 Improved logging of activities throug... Closed
relates to MODNOTIFY-70 Document patron notice functionality ... Closed
relates to MODNOTIFY-71 Patron notices - initial review of mo... Closed
relates to UXPROD-4685 create Jest/RTL test for RefundReason... Closed
relates to UXPROD-2384 Improved handling of send errors for ... Draft
Epic Link: Patron Notices
Back End Estimate: Medium < 5 days
Back End Estimator: Darcy Branchini
Development Team: Vega
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): R2
Rank: GBV (MVP Sum 2020): R2
Rank: Lehigh (MVP Summer 2020): R1
Rank: MO State (MVP June 2020): R1

 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 in order to improve this visibility of both successful and problematic processing of notices.

  • Improved logging of activities throughout patron notice process ( UXPROD-2394 Closed )
  • Monitoring of patron notice process with visual of system health (dashboard) ( UXPROD-2382 Closed )
  • Handling of errors for patron notices (i.e., retry sending) ( UXPROD-2384 Draft )
  • Notifying staff (of urgent errors and/or overnight stats) ( UXPROD-2385 Closed )

SPLIT: This feature is being split (April 2020) for each of these steps/options. Design will happen in Q2 with implementation happening in subsequent quarters. We are trying to include some of the implementation of the above in Q2.



 Comments   
Comment by Cate Boerema (Inactive) [ 27/Mar/20 ]

Hi Darcy Branchini. I just updated the estimate to 5 days back end per discussion in our cap plan meeting. The idea was to treat this as a timeboxed spike for Q2 to identify the points of failure and make a plan (to be implemented later)

Comment by Darcy Branchini [ 14/Apr/20 ]

Cate Boerema, Vega and I discussed this today and came up with several parts/ideas that go beyond simply notifying FOLIO admins of an error.

  1. Create a new module for logging errors at any point of failure related to notices (see list below)
  2. Create a dashboard for displaying/visualizing the "health" of each module
    • mod-circulation
    • mod-users
    • mod-template-engine
    • mod-event-config
    • mod-notify
    • mod-sender
    • mod-config
    • mod-email
  3. Retry send logic ( MODSENDER-14 Closed )
  4. Notify FOLIO admins of error causing emails to not send

And one more step. I recently updated notice documentation, and Vega also alerted me to workflow and sequence diagrams as well as DB schema documentation that they have as PDFs. As a first step, they are updating those and merging those into the Google Doc documentation created in Q4.

Comment by Cate Boerema (Inactive) [ 15/Apr/20 ]

Great. Thanks Darcy Branchini. Is the idea to create additional UXPROD(s) for the implementation of those features? I think we said that for Q2, we only had enough time to create a plan for future work. If that is still how we are proceeding, we probably should change the description of this UXPROD so folks don't think this will be fully addressed in Q2 (since this feature is assigned to Q2). Thanks!

Comment by Darcy Branchini [ 23/Jun/20 ]

Instead Vega wants to use the Core Platform approach - FOLIO-2644 Closed .

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