Hold Pull List Patron First and Last Name

Bug #1766640 reported by Steve Callender on 2018-04-24
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

This is semi-related to LP1728147 where Equinox had added a bunch of new fields to the hold pull list, but there are additional fields that have been requested.

Patron First Name
Patron Last Name

These fields were added to the grid display, but not recognized by the csv download output so this is a wishlist item to discuss/add those fields to the download output.

It looks also like any field being displayed on the screen that doesn't have a value will show as "null" in the csv output. It should come over as just blank rather than the words "null".

Scott Thomas (scott-thomas-9) wrote :

This is problematic for our libraries that generate pocket labels from Item Status .csv output (of which we have several).

Scott

Andrea Neiman (aneiman) wrote :

After some testing of the 'null' issue I think it is worthy of its own LP ticket, which I've created at bug 1766982

Changed in evergreen:
status: New → Confirmed
Scott Thomas (scott-thomas-9) wrote :

We just discovered that the Patron First Name and Patron Last Name also do not appear in Print Full Grid in the Holds Pull List.

Scott

Michele Morgan (mmorgan) wrote :

I have concerns about including the patron name on printed pull lists. This is a confidentiality issue for our consortium. We would prefer names not be available on printed pull lists at all.

I'm curious what the use case would be for names to appear on a list that's taken to the stacks to pull items for holds, where there's a danger it could get left behind. Care would need to be exercized in disposing of the printed pull lists as well.

I would stress that the name should not be on pull lists by default. If there's a need to have it at all, it could be made available so the field could be added by a staff user configuring the list.

tags: added: holds webstaffcolumns
Terran McCanna (tmccanna) wrote :

I agree they shouldn't be on the default printed list, and they're not something we would want to use in our public libraries, but I could see use cases where the patron names might be useful (for example, an academic library might want to prioritize holds for faculty).

Mike Rylander (mrylander) wrote :

Terran, I can understand the thinking behind the faculty use case, unfortunately the person's hold for whom the item is currently targeted is not necessarily (and in a busy system, even often) the hold that the item will fill at scan time. The specific hold that the copy is attached to on the pull list is for all intents and purposes an artifact of how the hold and copy data is stored.

The hold that will actually be filled is determined by the capture-time hold sort order, which can take things like profile group into account. The way to be sure that faculty holds are filled before student holds on the same title, all else being equal, is mark faculty groups with a higher hold priority than students, and to include that attribute in the hold sort order (which it is, by default).

Question for everyone: are there use cases that do not involve the eventually filled hold where the patron details are useful on the pull list specifically? (I can't think of any, because of the lack of a real connection between hold and copy when dealing with the pull list, but I may be missing something important.)

Terran McCanna (tmccanna) wrote :

>>the person's hold for whom the item is currently targeted is not necessarily (and in a busy system, even often) the hold that the item will fill at scan time<<

Ah! That's good to know, I didn't realize that part of the process worked that way.

Scott Thomas (scott-thomas-9) wrote :

I heard back from the library that brought this to my attention:

"It only helps us in the instance where we have a large list - we try to get as many books pulled as we can before the bins get picked up so we might pull those books first. It's usually pretty easy to spot the names of our regular patrons when we go through the list."

I have a more basic question: was suppressing Patron First Name and Patron Last Name in Print Full Grid an intentional decision or just an oversight? They are not suppressed in XUL.

Scott

Jessica Woolford (jwoolford) wrote :

For some of our public libraries, they might not want the name to appear on the printed pull list, but they may want it to show up on the pull list on the screen. Often libraries use a staff card to request multiple copies of a title for book clubs. The card often has "Book Club" in either the first or last name field. We have some libraries that don't want to sent their books for these requests, so they retarget those holds.

Scott Thomas (scott-thomas-9) wrote :

I understand the confidentiality concerns, but, if a library has such concerns, they can opt not to display the columns and they therefore would not appear in Print Full Gride. They can be displayed in XUL so, unless there is a good technical reason to suppress them in Print Full Grid in Webby (if the library desires it), it should be possible.

Terran McCanna (tmccanna) wrote :

This is being brought up again by our libraries now that they no longer have XUL available (where the names did print).

Changed in evergreen:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers