Versions Compared

Version Old Version 11 New Version 12
Changes made by

Laurence Mini

Laurence Mini

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

TimeItemWhoDescriptionGoals/Info/notes
2minAdministrivia

Jana Freytag

App Interaction SIG request:

Invitation: I would like to invite you to a related discussion with the App Interaction SIG on Friday, June 11th at 11:15 am ET / 4:15 pm UK / 5:15 pm CET.

→ Quick update on that and preparation for the meeting tomorrow

--------

FYI: The live captions are uploaded here: https://drive.google.com/drive/folders/0B7G8S7WF6N20NkVtc0x6ZmwxaGc

20MinGap Analysis

Jana Freytag

Another look at our updated gap analysis: Gesammelte Gaps deutscher Institutionen (in English)



20 MinScheduled notices

Lisa Sjögren (EBSCO) julie.bickle Darcy Branchini

https://folio-project.slack.com/archives/C3G05TF3R/p1622637942064600

  1. On scenario is where an overdue item gets a recall, and the library has configured recalls to change the due date but to _not_ extend the due date. This triggers the scheduled notices to be regenerated based on the original, already past, due date. The patron gets a recall notice and all courtesy and overdue notices scehduled to be sent up until the date of the recall.
  2. The other scenario is where you migrate overdue loans using the check-out-by-barcode API. When the loan is created, scheduled notices are generated based on the due date, which is already in the past. The notices with the nexRunTime in the past are sent out along with other delayed notices.


Lisa's original writeup of the recall scenario:

  1. 2019-11-29: 1204168883 is checked out by PatronA. The original due date of the loan is 2020-02-29. As per the standard notice policy, 3 OD notices are shceduled to be sent out in the weeks following the due date.
  2. Repeatedly during spring/summer 2020: before the due data is reached, the loan is given a new later due date. The old OD notices are replaced with new ones scheduled to be sent out in the weeks after the new due date. (This is done through a scripted process which uses the circulation/loans API.)
  3. Sometime in August 2020: the loan is given a new due date of 2020-09-29. The old OD notices are replaced with new ones scheduled to be sent out in the weeks following 2020-02-29.
  4. 2020-09-29: the loan expires. In the following weeks, the 3 scheduled notices are sent out.
  5. Winter 2020-2021: the library adds 5 additional notices to the standard notice policy.
  6. March 2021: the loan has still not been returned, and the patron hasn't heard from the library since the 3rd OD was sent in late 2020.
  7. 2021-04-11: the loan is recalled by PatronB. Since the loan is already overdue, this does not affect the due date. The due date is still 2020-09-29. The recall action triggers the scheduled notices to be generated. As per the standard notice policy, 8 OD notices are scheduled to be sent out in the weeks following 2020-09-29. Seeing that the there are now 8 delayed scheduled notices, FOLIO sends all of these notices to PatronA ASAP. (FOLIO does not care if the notice is delayed by an hour or 7 months, but the patron may.)

...

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to supporting materials

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue




























For the Ap Interaction SIG we want to have as many RA use cases described as possible, to make sure that all possible problems with data not getting synced are brought to the attention of the Ap Interaction SIG. Cases where data is not being kept in sync should be noted. One example would be a request for an item on order – this would require syncing of data between Requests and Users and between Requests and Inventory. Another example would syncing from lost & charged status and inventory. See  Ap Interactions RA SIG members should add any more use cases they can think of.

...

Question was raised as to whether there was ever a need to have a newly created notice to have a runtime date in the past, and if blocking created notices from having a runtime date in the past could solve this issue.

Lisa described another situation that arose at Chalmers. A very overdue item was recall-requested. Recalls normally change the due date of an item, but Chalmers has selected the option to never have due dates extended into future times. Therefore, when the item was recalled, the due date was changed to the same due date it had been. This 'change' in due date triggered the sending of the recall notice, and also all the courtesy and overdue notices were re-sent, creating confusion for the patron.

Brooks suggested that having the due-date-change fail in this situation (changing a due date to the same due date) as a possible solution.

Darcy said there has been discussion on how to handle the different situations types of notices for recalling an overdue item, or vs. having a recalled item become overdue, etc.

...