Hold Pull List Patron First and Last Name

[Steve Callender]

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.

[Steve Callender (stevecallender)]

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)]

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

Scott

[Andrea Neiman (aneiman)]

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

[Scott Thomas (scott-thomas-9)]

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)]

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.

[Terran McCanna (tmccanna)]

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)]

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)]

>>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)]

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)]

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)]

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)]

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

[Jessica Woolford (jwoolford)]

Here is another use case for having patron name on the pull list (especially now that lots of libraries are using curbside pickup): "We are running the pull list and getting books upstairs and downstairs so if the name was printed on the list, we could coordinate patron pickups. Guess we'll have to make do. In the old system we used it a lot to consolidate items and limit holds so I am disappointed because now it is right there and I can see it but doesn't print."

[Terran McCanna (tmccanna)]

FYI - until this bug is fixed, I've found that if you have the patron name displaying on the grid and you use the browsers File > print function it will print the names. (But then you have to do it with each page if you have more than 100 items.)

[Terran McCanna (tmccanna)]

Changing status to Wish List since this does work already with Print Full Grid.