2017-11-20 Resource Access Meeting Notes

Date

20 Nov 2017

Attendees

• Andrea Loigman

• Michael Winkler

• Rameka Barnes

• Cate Boerema (Deactivated)
• Joanne Leary
• Tania Hewes
• Holly Mistlebauer
• Mark Canney
• Deb Lamb
• Wendy Wilcox
• David Bottorff
• Kimie Kester
• Maria Grzeschniok
• Cheryl Malmborg
• Carsten Schwill
• Ginny Boyer

Discussion items

Notes

Housekeeping

• Ginny Boyer is the Director of Strategy for OLE and joined us for our meeting.  It was her first SIG experience.  Welcome Ginny!
• No meeting on 11/23, which is the US Thanksgiving holiday.  No meetings on 12/25, 12/28 or 1/1/18.   Should we meet on 12/21 (note taker says no).  Please send you thought to Andrea.
• UM-SIG meeting.  Andrea will work with Chris Manly to find a time they can join us at one of our regularly scheduled meeting times.

Tania Fersenheim and terminology

• What is the appropriate status for a request that has not been acted upon at all
• Open – hasn’t arrived
• Request status is independent from item status
• Built in place holder for future needs
  
  • Using “Open - _______”
• She would like to see screen shots of Illiad status
  
  • • Put in wiki
• Request queue – if an item is #1 in the request queue, does that determine the item status that is displayed?  Yes.
• The issue of more than 1 status will be put in the parking lot.
• Please send her screen shots of your current system request queue by placing them in the wiki

Holly Mistlebauer and manual fees/fine pages

1)     Finalize Open Fees/Fines page:

• Modal not necessary—just go to the Fee/Fine detail page. 
• Need a way to add a note as an action—doesn’t involve a dollar amount.  Need the date and a note.  Need to be able to edit a note.
• Show dates only as applicable for the fine—may need a fine type.  Will discuss this more as part of automated fines.
• Filters should show what is appropriate for the particular user and show a count (e.g. Waived (5)).
• Order for filters should be:  Owner, Payment Status, Fee/Fine Type, and then Item Type.  
• Filters should be sorted alphabetically.
• When user sorts a date column, sort dates within transactions too.

2)     Should we add total fees/fines to User Details Fees/Fines section?  Yes, but we need to somehow separate debits and credits.  We will wait until after we talk about paying/refunding fees/fines, when this will be clearer.

Request Queue Screenshots (Chicago)

Here are screenshots of the request search screen in OLE. The main takeaway here is that the ability to re-order a request queue is dependent on the kind of search one does. Searching by item means that changing the request queue makes sense, while searching by patron does not. One of the big frustrations of OLE (or it would be, if we re-ordered requests more often) is that OLE has a completely separate lookup solely for re-ordering request queues.

Request Queue Screenshots (VZG)

(Please ignore the ancient request dates, this is a screenshot from a test system that is not frequently used.)

When a barcode/item was selected in another screen and the operator chooses „Vormerkungen“ (requests) in the menu on the left side this screen shows up.  In the first tab “Vorm” changes to the request queue can be done. The column “P” indicates the priority of the request. The value 5 is a default. Changing this default results in rearranging the request queue, which is usually sorted by the request date (column “Vorm. am”).

Request Queue Screenshots (Duke - Aleph)

Like most of Aleph this is a lesson in 'meh'.  If reordering requests was something we did with any frequency this would be completely untenable.  Because it is something that only occurs rarely it's not that big a deal.   More problematic is the ability (or lack thereof) to move requests from one item to another.  The oly way Aleph permits this requires flipping back and forth between items, keeping track of which patron has which priority, deleting the original requests and creating new ones on the correct item all the while trying to avoid sending automatic cancellation notices to the patrons (which requires telling the system that I want print notices each time).

In the first screen we're seeing all of the items on a single Bib - there are a combined 3 requests for the first 2 copies  - note counts in the Requests column.  There is no way to see details of the requests for all of the items (this is really annoying). To see the details including requesters and their current order you must select a specific item and then click on "Hold requests" in the left hand section of the screen.

In the second screen we're seeing a queue of 4 requests for a single copy.  The right hand column lists priority and you can see that one request added for me on 11/29 has a priority of 00 and is at the top of the list (default is 20).  This will not trump the current hold but it will trump the person waiting in the queue since 9/27 who should be ahead of me.  There is also a request placed 11/29 with a priority of 30.  This is the lowest priority and will remain at the end of the list unless adjusted.  Priority can be set at request creation or edited at a later point.  To reorder a queue you have to repeatedly reset priorities until the list is in the desired order.  Aleph would allow us to add more priority levels if we needed them.

Request creation / edit screen, where you can alter the priority.