Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2385

Improved logging related to patron notice processing

    XMLWordPrintable

    Details

    • Template:
      UXPROD features
    • Epic Link:
    • Back End Estimate:
      XXL < 30 days
    • Development Team:
      Vega
    • Calculated Total Rank:
      105
    • 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 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.

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                dbranchini Darcy Branchini
                Reporter:
                dbranchini Darcy Branchini
                Back End Estimator:
                Oleksandr Vidinieiev Oleksandr Vidinieiev
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases