Versions Compared

Old Version 13

changes.mady.by.user Laurence Mini

Saved on

compared with

New Version Current

changes.mady.by.user Laurence Mini

Saved on

Key

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

Date

Attendees

...

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: ALT 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..

David raised the point that where Fees/Fines are concerned, data syncing could be problematic. For example, if a fee is charged on an item when it was a reserve item, and the item is the taken off reserve, the fee/fine should still reflect the fact that the fee was charged at the time when the item was on reserve – in this case the historical data should be preserved. SIG members could not think of any other area where syncing would cause difficulties.

Jana and Brooks will be attending the Aps Interaction SIG tomorrow. Jana will post a link to the recording.


Gap Analysis: See Jana's Gap Analysis. Some of the gaps between desired and available features have no UXPRODs/JIRAs and so have not been ranked. For example, there is no JIRA for automatic slip printing. Andrea offered to write user stories for the gaps with no JIRAs.

...