SIP2 Hold Items Count Includes Unavailable Holds

[Jason Stephenson]

Evergreen: 3.0.13
OpenSRF: 3.0.1
PostgreSQL: 9.5

The hold items count in Evergreen includes the unavailable holds in the count, and the list of Hold Items in the AS fields does as well. At least one vendor, Biblioteca, considers this a bug.

The 2007 revision of the 3M SIP2 document is not very useful in this respect. It defines hold items count as follows:

4-char, fixed length field. This field should contain the number of hold items for this patron,
from 0000 to 9999. If this information is not available or unsupported this field should contain
four blanks (code $20).

The hold items, field AS, is described thus: "variable-length field. This field should be sent for each hold item."

The unavailable holds count is defined as follows:

4-char fixed-length field. This field should contain the number of unavailable holds for this
patron, from 0000 to 9999. If this information is not available or unsupported this field should
contain four blanks (code $20).

Unavailable hold item, field CD, has the following definition: "variable-length field. This field should be sent for each unavailable hold."

Given that there are two separate fields, and the interpretation of "hold items" as "hold items available for pickup" seems most useful to the patron, I am siding with Bibliotheca in this interpretation of the hold items count and hold items fields.

I will share a branch to make that change shortly.

[Jason Stephenson (jstephenson)]

Pushed a fix branch to user/dyrcona/lp1799272-limit-sip2-hold-items-to-available in the working repository.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1799272-limit-sip2-hold-items-to-available

[Jason Stephenson (jstephenson)]

This comment is mostly for the benefit of Jeff Godin, who asked in IRC.

This started on an internal ticket at CW MARS:

    We are noticing a problem with holds not displaying properly
    on our self checks. I presented the problem to Bibliotheca
    support today. They said that in the logs they noticed that
    the information that they were receiving from the ILS (for
    holds) was duplicated. For example, a patron will use the
    self check and it will tell them that they have 2 holds and 1
    is available. When you look at the patron's account in the
    self check it has the same hold listed twice, once as
    available and once as unavailable. When they go to the circ
    desk to retrieve their hold, there is only 1 hold listed but
    it is really not available. Bibliotheca said that they would
    send me a log file which I will forward to you once I receive
    it.

When I got a log file, it showed something different from the description above. There were two patron information requests, one for hold items, and one for unavailable hold items. The hold items response had 3 items listed. The unavailable hold items response had 1 item listed that was included in the hold items list. This is where I think they get the idea that the holds are "duplicated," though I have no idea how it displays in the self check. I can't share the log file because I assume that Bibliotheca claims ownership of the contents and because it has pesronally identifiable information about a patron in it.

I tested with the same patron using a PHPSIP2 client and got the same results. The unavailable copy appeared in both the hold items and unavailable hold items counts and lists.

[Jason Stephenson (jstephenson)]

I have pushed a better branch for this bug. It makes the change in behavior optional by adding an implementation option for the oils_sip.xml file: msg64_hold_items_available. I have also added release notes to this branch:

working/user/dyrcona/lp1799272-sip2-hold-items-available-option

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1799272-sip2-hold-items-available-option

It works in my testing so far, and the old behavior is there if you don't add the option to a particular institution. We are likely to start using this feature in production, soon.

[Jason Stephenson (jstephenson)]

CW MARS has been using the branch mentioned in Comment #3 since we upgraded to Evergreen 3.2.4 on April 14, 2019. The site that we implemented this feature for is happy with the change, and the other sites that don't use the setting don't know it's even there.

[Galen Charlton (gmc)]

While reading the patch, a question occurred to me: would it be useful to also consider shelf_expire_time and not count a hold as available qua "on the holds shelf" if the shelf expiration time has passed?

[Galen Charlton (gmc)]

(I can see arguments either way: if the expiration time has passed, it is has passed; or, if the patron manages to beat the library staff to picking up the item from the holds shelf, it's still fair play.)

[Jason Stephenson (jstephenson)]

I can see arguments either way, and I prefer to leave the code unchanged. I hesitate to add yet another option to handle hold shelf expire times.

The main problem that we're trying to solve is to not return a patron's unfilled holds because they may then think that these unfilled holds are available. We haven't had any reported issues with expired holds in the 2+ months that we've been using the code.

[Galen Charlton (gmc)]

Pushed to master for inclusion in 3.4. Thanks, Jason!