2023-09-21 Resource Access Meeting Notes

Owned by Cornelia Awenius
Last updated: Sep 25, 2023 by Thomas Trutt
5 min read


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

Thomas Trutt 

Note taker:

Chat: 

11:02:33 From Tobi Hines To Everyone:
    That's not very convenient!
11:06:17 From Erin Weller To Everyone:
    In our prior system, we limited all requests to 10.
11:07:05 From Sarah Johnson To Everyone:
    If a library deals with a large amount of requests overall, they might want to limit the number per person based on staff bandwidth
11:07:16 From Susan Kimball To Everyone:
    We limited to 20 until the hold was fulfilled/cancelled
11:07:32 From Susan Kimball To Everyone:
    Reacted to "If a library deals w..." with 👍
11:07:46 From Karen White To Everyone:
    Can requests be limited by patron group?
11:07:54 From Erin Weller To Everyone:
    Good question Karen!
11:09:14 From David Bottorff - UChicago To Everyone:
    material type isn't relevant to us but loan type
11:09:16 From David Bottorff - UChicago To Everyone:
    is
11:12:23 From Susan Kimball To Everyone:
    Reacted to "material type isn't ..." with 👍
11:14:34 From Erin Weller To Everyone:
    No I don't think we'd use that
11:15:06 From Erin Weller To Everyone:
    all of them
11:15:07 From Tobi Hines To Everyone:
    I would consider all of those open requests
11:15:10 From Susan Kimball To Everyone:
    Yes, all the open requests in FOLIO
11:15:17 From Claire Hoag (she/her) To Everyone:
    All of those
11:16:29 From Erin Weller To Everyone:
    yes
11:16:35 From Moentnish, Shirley J To Everyone:
    Yes, all the request.  If not found, we charge them to missing so they can go through ILL.
11:16:52 From Erin Weller To Everyone:
    yes again :)
11:16:54 From Susan Kimball To Everyone:
    Replying to "Yes, all the request..."
    
    Agreed, Shirley!
11:16:56 From Moentnish, Shirley J To Everyone:
    Yes.
11:17:18 From Tobi Hines To Everyone:
    But would staff override at the desk really meet the need? Most of our patrons place their requests online, yes?
11:19:38 From Moentnish, Shirley J To Everyone:
    We do not allow request on Reserves and only two reserves at a time.
11:21:01 From Sarah Johnson To Everyone:
    I would think they'd be capped at the 20
11:21:22 From Tara Barnett To Everyone:
    Reacted to "I would think they'd..." with ➕
11:21:37 From Moentnish, Shirley J To Everyone:
    Twenty seems more reasonable.
11:23:43 From Tobi Hines To Everyone:
    Yeah, agreed
11:23:51 From Erin Weller To Everyone:
    Yes let's start simple
11:24:11 From Moentnish, Shirley J To Everyone:
    Simple.
11:24:24 From Christine Tobias To Everyone:
    KISS
11:24:32 From Christine Tobias To Everyone:
    Keep it simple, sweetie!
11:24:43 From Moentnish, Shirley J To Everyone:
    Great.
11:24:58 From David Bottorff - UChicago To Everyone:
    gotta go, bye all!
11:28:16 From Claire Hoag (she/her) To Everyone:
    Yes - we'd love that option!
11:28:20 From Moentnish, Shirley J To Everyone:
    That would be great.
11:28:50 From Sarah Johnson To Everyone:
    I also have to jump out now. Thank you for discussing the limiting of requests.

Recording:



Limit number of requests per patron

Sarah Johnson 

Thomas Trutt 



Meeting Notes

 The topic of todays meeting was request limitations and how fine grained they should be, or how fine grained do institutions need them to be. Based on the conversations Jira(s) will be created.

 Points of interest:

  • It makes sense to limit the number of open requests a patron can have if they also have a limited number of items they can check out. for example if someone can only have 20 items checked out at once they should be limited to a number of open requests, at or below that level. 
  • Some institutions prior systems allowed for  a limitation of open request:
    • When a DVD collection was migrated to one unit requests went through the roof which caused processing issues for staff.
    • Olive has very fine grained limitations down to Material type, Loan type, and User type. 
    • Some patron groups may request a large number of items at the beginning of the semester. 

Q: Would a limit at the user type level be enough or is there a need for more fine grained control, at the request policy level?

  • There was an smaller interest in the more fine gained control.
  • Preference would be for a over arching limit and then later maybe work on finer limits. 
  • If put in place there seems to be inclination to have it act like check out limits where the user limit can not be surpassed.
    • Comments - this was a loophole in some LMS's as patrons could get around the limit by requesting 10 items form each location. 
  • The fine grained limits would need to include Material type, Loan type, and location; ie be part of the circulation rules to ensure all institutions could use it. 


Q: Should there be a limit on  the number of request a user can make in a given period?

  • There did not seem to be an interest in this as a new feature. 
  • David mentioned that UChicago does have a written policy they can refer to as needed. 


Q: What is considered and "Open" request?

The general consensus was that any request status that was any request status with the term "open" should count against the limit. This did start a side conversation around stale requests and how they are handled; below.


Q: Should front line staff be allowed to override the block? Is this a new permission?

Yes to both. Staff should be able to override the block and the ability to do so should be controlled by a permission.


Old request cleanup:

One topic that surface during the conversation was old or stale request cleanup. This topic was brought up as first a concernt that stale requests could count against patron limits, the second was how libraries are handling stale requests now.

In regards to the user limit, it was quickly decide that this would have to be a limitation of the system or handled via a staff cleanup. 

in regards to current cleanup procedures a few needs where identified.

  •  A way to easily identify 'stale' requests. Theses would be requests that have sat in a specific open status for a long period of time. 
    • Some libraries are running reports to identify theses requests and cancel them, which leads to point 2. 
  • There is no way to suppress a cancelation notice to a patron. When libraries do a manual cleanup of old requests the cancellation notices are sent to the patrons. 
  • Request expiration date: This was part my misunderstanding of the current state of this functionality. It appears that the expiration date is used and acted upon however. Notices are tied to separate event and therefor can be suppressed if a library wishes.  There are open ticket around automatically populating this expiration date, currently there is no default value set.


Tickets around request expiration:


UIREQ-676 - Getting issue details... STATUS

UXPROD-1628 - Getting issue details... STATUS

UXPROD-3539 - Getting issue details... STATUS

Action items:

Thomas Trutt will write up a new feature to cover the addition of a user open request limit: UXPROD-4474 - Getting issue details... STATUS

Future topics:

  • Refinement of the request expiration date
  • JIRA covering a more granular request limit; based on request policies (low priority)
  • Requirements around a stale request report or cleanup system
  • Requirements for a 'Do not send notice' function on the cancel request dialog box; julie.bickle