2022-09-26 Resource Access Meeting Notes

Previously, RA SIG met and discussed possible ways to assist POs and bring forward orphaned features. Jana proposes that we start a dedicated meeting every other Thursday to discuss PO assistance or engage in activities that would assist POs in moving features forward. The group agreed. Jana said she would let Julie know about the meetings.

Jana will set up a different day/time meeting for the CDL group (that was previously meeting on Thursdays) so that the MM folks could attend future CDL meetings.

TOPIC -- Magda Zacharska presented an overview of bulk edit with questions for the group about identifiers and loans preview columns that could be useful for circulation.

In the Nolana release, an in app approach for user records will be implemented where several fields can be updated through the UI.

For the Orchid release, they are planning to work on circulation data with updates to loan due dates and hold shelf expiration dates for requests

Example of how it works: The user provides the list of identifiers and drags the CSV file (created by running a query outside of the bulk edit app in whatever way each institution is running queries; queries inside bulk edit may be developed in future releases) into the bulk edit app. They start the bulk edit, specifying what they want to change. They confirm changes and are presented with a downloadable preview list of the records that will be modified. User chooses Commit changes. FOLIO shows the list of records that have been changed.

Magda asks -- What will be the appropriate identifiers for the records for requests, and for loans?

Identifiers will help identify the records for the bulk edit and also the columns that the user will see on the landing page. The list is pre-populated.

Magda met with the bulk edit working group last week, and they came up with the following list:

Loan Record Identifiers (columns for the users)

Loan UUID
Users UUID – probably least useful to circulation
patron group (patron group ID at checkout)
loan policy ID
item effective shelving location
Service point (checkout service point?)
Item UUID (also Hrid, barcodes?)
Due date (RA SIG request to add it)
User barcode (RA SIG request to add it)
Loan date (RA SIG request to add)

The most common use cases for updating the loan due date is a planned event in some library location or an unplanned weather or facilities-type event and the libraries need to close. For those use cases, you would mostly be searching by service point or location, not necessarily for patron group, or item UUID.

Another example – a calendar error and everything ended up being due on a date when we were closed. So we want to go be able to go back in and change everything that was due on those dates to push them back, beyond the Christmas holiday.

A weather issue may only impact a certain location, so that is an argument for adding location or service point.

There was discussion about the query taking place outside of the bulk edit app. The CSV file used in the bulk edit app will be created by running a query to create the CSV file first. The query portion may eventually be part of the bulk edit app, but not at the beginning.

With the Bulk edit app we have a list of the records that we want to change. We would check the validity of the data in the CSV before we work with the bulk edit app, and only import the things that are correct.

Magda asks for input on Columns that are being displayed.

You submit the list of identifiers, the system found the records that match the search criteria and returned the list. This is the list of columns that display before making bulk edits:

Loan Previews columns:

Item title – is this useful?
Item status
Due date
Requests
Barcodes
Fees/fines incurred – is this needed? Possibly for libraries that have daily overdue fines applied?
Effective call number string
Renewal count – is this needed? Chicago says yes
Loan policy
Contributors – Is this useful?
Location
Loan date
Loan status (RA SIG request to add?)

Magda proposed that we table this conversation. She will talk with the developers to see how much complexity we are adding to the implementation by including those columns. And then she will ask RA SIG to review. She wants to check on performance impacts with this first.

Additional questions from Magda (RA SIG answers in bold):

Should loan due date changes be allowed for overdue loans? Sounds like yes, we need this option
What about recalls? Some say yes (weather issues) and some say no (only recall for reserves). Concern expressed about limiting this to no (in the case of Pandemic or weather closures that may change policies and actions taken) – want to have the option.
What about overdue recalls? no those shouldn’t be changed? – may need the option though. We can change the due date now on a single record as an override. In bulk edit there wouldn’t be bulk override.
What is the impact of allowing due date changes on other request types?
Any loan statuses that should not have their due date updated? (open or closed)
Any item statuses that should not have loan due dates updated? (declared lost, claimed returned, aged to lost? RA SIG agrees that these statuses should not have loan due dates updated because of potential underlying business logic with fees/fines, etc.
What should expected behavior be when the entered data is invalid? Error message that includes the entered data so that you can track down why (e.g., not updated because aged to lost) only errors on the problem items (e.g., three that could not be updated IDs and other info on the loan listed)
What should be specified as the loan action? Updating due date is the average due date action. Should we differentiate this between single records or bulk edit? Yes
and how will this value be used in FOLIO? Loan detail that specifies whatever was done and that it was done by bulk edit.
What impact with loan due date have on fees and fines?
Would loan due date change impact loan policies? If yes, how?

In bulk edit, we have the option on the confirmation page once the bulk edit completes, there is additional accordion with errors. For example, if the item record could not be updated, if the record has status not supported in bulk edit, you get the list of the records that could not be updated. Similar issue with the overdue recalls where you get the list, and then you would need to do them manually outside of bulk edit.

Magda is asking for RA feedback in the Slack channel on the last two bulleted questions.

She will join us at a future RA SIG meeting with additional questions and to talk over hold shelf expiration date with bulk edit.