2022-07-11 Resource Access Meeting Notes


Date


Recordings

Find all recordings here: https://recordings.openlibraryfoundation.org/folio/resource-access-sig/

Zoom

https://zoom.us/j/337279319 (pw: folio-lsp)

Attendees

Erin Nettifee 

Thomas Trutt 

Elizabeth Chenette 

julie.bickle 

Tobi Hines

David Bottorff 

Brooks Travis 

Laurence Mini 

Stephanie Buck 

Andy Horbal 

Robert Scheier 

Monica Arnold 

Laszlo Jakusovszky 

Christiane 

Rebecca Pernell 

Martina Tumulla 

Erin Weller 

Mark Canney 

Molly Driscoll 

Kimie Kester 

Cheryl Malmborg 

Amelia Sutton 

Christine Tobias 

Jana Freytag 

Discussion Items:

TimeItemWhoDescriptionGoals/Info/notes
5minAdministrivia

Note Taker: Molly Driscoll 

meeting_saved_chat.txt

meeting_saved_closed_caption.txt

30MinTitle Level Request scenarios 
20MinWOLFCon Planning@ all
Julie's brainstorming for working sessions:
_ Workshop: How can printing letters look like in FOLIO?
_ FOLIO and Patron Communication - are there new trends that FOLIO should consider?
_ FOLIO and Ressource Access - are there new trends that FOLIO should consider?

Meeting Notes

  • Tobi Hines (Cornell) has joined the SIG and introduced herself
  • Julie led a discussion of https://folio-org.atlassian.net/browse/CIRC-1558
    • This had been entered as a bug, under advice of the developers
      • However, this may be considered more of a missed requirement
    • Uncovered by Marie at Chalmers in testing
    • When a TLR does not have an item assigned, item information does not appear in tokens related to the staff slips and notices
      • This includes even information that should come from a higher level, like the instance – title, primary contributor, all contributors
    • Quick fix:
      • If the item info cannot be found for item.title, item.primaryContributor, item.allContributors, get this information from the instance.
        • Downside: not fully transparent
        • Upside: resolves for Morning Glory with launch of TLR
      • Longer term wish list
        • Having separate policies dictating a notice template to use for TLR versus item requests
      • Confusion about whether current request notice implementation for TLR adheres to defined requirements
        • Should TLR templates only be engaged when no item is associated?
      • Resolution:
        • Quick fix to be included in Morning Glory
        • Julie and Steph to touch base offline about clarifying additional requirements and documenting what changes are needed
      • Steph led a discussion of further TLR scenarios based on user acceptance testing
        • Outlined here: https://docs.google.com/presentation/d/1em3iML1J3F6VthKcMjPNhjfSTOVy39TQxR9V-JBVE5I/edit#slide=id.p
        • Scenario 1: If pages are not allowed (by circ rule) and there is an available item on the record, the request fails. This is expected for item requests. What should happen for TLR?
          • Discussed how this relates to https://folio-org.atlassian.net/browse/UXPROD-2649
          • Prevented reason needs to be returned via the Edge APIs
            • Brooks: “The edge apis already return the reason. The edge API should automatically handle this case by placing the hold.”
            • This would result in an “orphaned” TLR, which would need to be reported on somehow.
          • Resolution: the group agreed that the potential solution outlined in the slide deck seems correct: “The user gets a message that the request couldn’t be completed because of patron and circulation rules. After that message is cleared, we’d want to offer the same request as a hold. Interface could alert the operator and provide the option to create the request as a title-level hold, similar to what happens when you move an item-level page or hold to an item that has a status that doesn't allow the current request type (this would be similar to the mod-patron title-level request api behavior)”
        • Scenario 2: An item is checked out to Patron A with Patron B and Patron C in line. Patron A returns it which triggers the hold for patron B, but that hold is Open – Not Yet Filled because the item has to travel to their pickup point. If Patron B then cancels before it arrives for them, how does it get triggered for patron C?

If it’s a page Open – Not yet filled that is cancelled, nothing now happens to trigger the hold for the next patron.

  • Brooks: Item level pages change the item status back to "Available” when cancelled. I need to test how this behaves for item-level requests. because I can see the same issue there…
  • Laurence: Expired requests, don't think status changes.
  • Resolution: Potentially creates orphan request which needs to be addressed by workflows and reports on the library side until FOLIO addresses orphan requests. Needs documentation for how to address orphaned holds, but no current development
  • Jana led a discussion on Wolfcon sessions
    • Expressed support for Julie’s working session ideas in the agenda
    • Reviewed RA related sessions within the overall schedule
    • Sessions are scheduled in the European afternoon to facilitate US attendance
    • Potential to add sessions – please start a conversation in Slack! Will also have a follow-up conversation at an upcoming meeting.