2023-07-27 Resource Access Meeting Notes
Date
Recordings
Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/ (pw: folio-lsp)
Zoom
https://zoom.us/j/337279319 (pw: folio-lsp)
Attendees
Discussion Items:
Time | Item | Who | Description | Goals/Info/notes |
---|---|---|---|---|
5min | Administrivia | |||
Open Discussion round | all |
| ||
from last meeting: | Gaps that came up during the meeting |
|
Meeting Notes
Would like to create awareness of gaps and prioritize which ones are most important. Please continue to add gaps to document – will discuss at future meeting.
Should we skip gaps where there is no PO, such as fees/fines? Could leave in and hope that someone can take ownership of that specific issue, even if unable to be full PO.
Should look at the gaps on the list and identify which issues are still open, vs which may be already done or scheduled to be done for the Poppy release.
Actual Cost is on list, but is it already done? Still needs work in Patron Notice area (Julie is working on these) and Circ Log area (no one working on this right now).
David and Thomas gave explanation of 3-part item state (see also slides at Item state - what we know so far). The 3-part item state would help handle staff processes more easily, such as when an item is needed for repair work, and/or cataloguing. Would avoid having to use dummy accounts. 'Needed for' state could be used to indicate an item is needed for a patron request, Preservation, Cataloguing, etc. Also allow establishing what gets priority (patron request given priority over cataloguing, for example). Would also help automate things, instead of having to put in manual recall to get something back to be repaired, etc.
Some other systems can do part of 3-part item state capability (Voyager allows assigning multiple item statuses to an item; Alma has a 'needed for' functionality), but 3-part item state would go beyond what any other system has to offer.
Tom speculated whether having a workflow engine might replicate some capability of the 3-part item state, allow it to be scaled down. Work is being done on allowing third-party workflow engines to be integrated into FOLIO
David questioned whether such a large endeavor as the 3-part item state should really be a 'gap' or if it is better to focus on narrower needs that institutions badly want and that can be addressed more quickly.
Cornelia agreed that we should define the gaps more specifically. For instance, we should say which specific patron notice refinements we most want.
David asked for feedback regarding other institutions sentiment about the two issues he most highly prioritizes – having separate notices for recalled items; and automatic renewals. Thomas was 50-50 on the first one. They use wording ('if this is a recall, then ....) to cover all cases. David said that their patrons find this confusing. It was agreed that having separate recall notices would be nice, less agreement on whether it should be a top priority. For automatic renewals, Thomas mentioned upcoming expansion of capability of Bulk Edit as a work-around. David said that while bulk-editing of due dates is important to have, it is not a renewal, bypasses circ rules, lack of record, etc. and is a clumsy work-around for auto-renewal.
Cornell would like to see improved fee/fine export to Bursar.
David and Cheryl agreed that searching for a user in Users app is unacceptably slow. Does not seem to be a Jira for this, people are just living with it.
Cheryl mentioned that the Claims Returned process is not complete. David agreed, said would be #4 on his list. The inability to cancel a claims-returned (you either have to close the loan by marking as missing, or bill the patron) is frustrating.
Issue was raised as to desirability of being able to optionally add Department as a subcategory of Patron Group in circ rules. Libraries that only use a few patron groups (staff / undergraduate / graduate) might find this useful.
Magnus asked if other institutions are having issues with self-checkout machines handling automatic patron blocks differently from manual patron blocks. Answer: yes, other places have this problem where automatic blocks don't show a block when the patron swipes their card, only when they try to check out an item. David said that they found many short-comings in FOLIO SIP2, so they had a custom version built. Offered the code back to FOLIO, haven't heard back yet. Work is being done by FOLIO group to improve SIP2 for check-in and patron status info. Cornelia will ask Axel for an update on SIP2, possible future SIG meeting topic.
Jana asked SIG members to continue to add specific gaps to gaps document. Will plan a future meeting, after WolfCon and when people are back from vacations, to discuss further which gaps we want to give top priority to closing.