Patron Notices (UXPROD-18)

[UXPROD-2221] Custom stop/end for recurring patron notices Created: 07/Jan/20  Updated: 23/Feb/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: notice_enhancement, notice_timing, patron_notice
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Potential Workaround: Using the current notice policy several one time notices using the same template could be setup to accomplish this. For example, if a library wants to send overdue template #1 from day 1 through day 3 after an item is overdue and then overdue template #2 on days 4 until the item is returned or renewed, you could do this using the following settings:

*Notice 1:*
Template: Overdue template #1
Triggering event: Loan due date/time
Send: After by 1 day
Frequency: One time

*Notice 2:*
Template: Overdue template #1
Triggering event: Loan due date/time
Send: After by 2 days
Frequency: One time

*Notice 3:*
Template: Overdue template #1
Triggering event: Loan due date/time
Send: After by 3 days
Frequency: One time

*Notice 4:*
Template: Overdue template #2
Triggering event: Loan due date/time
Send: After by 4 days
Frequency: Recurring, And every 1 day



Epic Link: Patron Notices
Front End Estimate: Large < 10 days
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Development Team: Volaris
Kiwi Planning Points (DO NOT CHANGE): 11
PO Rank: 50
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R4
Rank: Grand Valley (Full Sum 2021): R4
Rank: hbz (TBD): R4
Rank: Lehigh (MVP Summer 2020): R2
Rank: Mainz (Full TBD): R3
Rank: MO State (MVP June 2020): R4
Rank: U of AL (MVP Oct 2020): R1

 Description   

Description:

Some notices can be setup to be sent with a frequency of recurring (versus one time). The notices that can be setup as recurring include time based notices triggered by loan due date/time, hold shelf expiration, and/or request expiration. Typically these include courtesy/reminder, overdue, available - awaiting pickup (for requests), hold shelf expiration and/or request expiration notices. An example would be to send overdue template #1 everyday from day 1 through day 3, then send overdue template #2 everyday until the item is returned, renewed or an automated fine has been incurred by the patron.

Current implementation:

  • All notices setup to send before the triggering event of due date/time stop sending automatically when the item is due – typically these are courtesy reminder notices telling the patron that an item is coming due.
  • All notices setup to send after the triggering event of due date/time stop sending automatically when the item is returned or renewed – typically these are overdue notices telling the patron that an item is overdue.

Proposed implementation (this feature):

  • Allow a FOLIO operator to select one or more stopping event or date/time. Examples include stop sending upon/at due date/time, item returned, or item renewed – or – after due date/time by 3 days (using the current order/terminology of the policy).

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