2021-06-10 Resource Access Meeting Notes

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

Notetaker: Laurence Mini

20Min

Gap Analysis

Jana Freytag

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

20 Min

Scheduled notices

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

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

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

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.
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.)
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.
2020-09-29: the loan expires. In the following weeks, the 3 scheduled notices are sent out.
Winter 2020-2021: the library adds 5 additional notices to the standard notice policy.
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.
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.)

Meeting Outcomes

Functional Area	Product Owner	Planned Release (if known)	Decision Reached	Reasoning	Link to supporting materials
e.g. loans, fees/fines	Name	e.g. Q4 2018, Q1 2019	Clearly 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 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.

Thomas mentioned that it would be good to have a way to see what has and hasn't been printed. Jana agreed, and added that it would be good to have a way of re-sending to the printer those things that did not get correctly printed.

With regards with the issue of knowing on what printer something printed, Erin explained that this is very hard to do without having a desktop ap.

It was agreed that there would be a one-meeting subgroup (Darcy, Julie, Jana and Erin) to create user stories.

Hidden / Visible Permissions: Thomas described issues that can arise with having some permissions being hidden and others visible. Should there be an easier way to view hidden permissions? Currently viewing hidden permissions is linked to the session, and expires when the session is over. If someone has hidden permissions and then permissions are later edited without having the hidden permissions visible, this can cause the hidden permissions to be over-written.

Lisa joined the meeting to discuss the problem of Scheduled notices with NextRunTime in the past (see Slack discussion). This can result in a patron receiving a bunch of different notices at once, causing confusion to the patron and headaches to library staff.

Darcy explained that there are three different types of notices: recurrent notices, where sending a notice causes the scheduling of the next notice; notices which are sent as result of item state changes; and session notices that are sent at the end of a check-in/out session. Due date courtesy/reminder notices are scheduled and created when an item is checked-out, and then they lie in wait to be sent at the appropriate time.

The problem with loans migrated from another system, where some loans may have due dates in the past, has been documented by Texas A&M. The work-around is to turn off email notifications during the loan migration, and remove notices with a due date in the past before turning email notification on.

Question was raised as to whether there was ever a need to have a newly created notice 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 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 types of notices for recalling an overdue item, vs. having a recalled item become overdue, etc.

Marie, Lisa, Cheryl and Darcy will meet to discuss this issue further.