Collections "users of interest" API causes error when retrieving a null card

[Chris Sharp]

This is a very old bug, found and fixed locally for PINES by Mike Peters, then of Emerald Data Networks. Adding his description from the commit message here:

    If the open-ils.collections.users_of_interest API encounters a patron that
    has a null "card" value in actor.usr the API will crash with an error like:

    Received Exception:
    Name: osrfMethodException
    Status: *** Call to [open-ils.collections.users_of_interest.retrieve] failed for session [1416515351.333446.1416515351406], thread trace [1]:
    Can't call method "barcode" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Collections.pm line 299.

Branch on the way.

[Chris Sharp (chrissharp123)]

Branch here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1996938_fix_users_of_interest_api

Signed off because we know it works. I will wait a bit before pushing in case people want to review, but mocking up a test would be pretty complex and it's a straightforward change.

[Mike Rylander (mrylander)]

It would certainly be good to fix this to protect against "bad data", but it may be worth looking into how such users were created. There should be no way to create a user without a card in any human-accessible interface.

[Mike Rylander (mrylander)]

Actually, having looked at the patch, it's not clear how the change in syntax is actually changing the behavior of the code.

If $u->card returns undef, then the ternary op ?: will use the "false" branch in either version of the code. Is there some analysis of the original construct that suggests calling defined() instead of testing the result of $u->card for truthiness is actually different here? It's not beyond Perl to change operator precedence (say, now => binds more tightly than ?: or some such), but this case in particular seems ... unlikely.

(UPDATE: I checked the perl docs, and, no, => does not bind more tightly than ?: ...)

[Jeff Davis (jdavis-sitka)]

I can't replicate the issue with current master on Ubuntu 20.04.

To test, I used srfsh to send this request:

request open-ils.collections open-ils.collections.users_of_interest.retrieve "<authtoken>", 1, 5, "BR1"

The response included info for 3 patrons. I set actor.usr.card to null for one of those patrons, then repeated the request. I got the same response with the same 3 patrons, except that one of the users now had barcode = null. I did not get an error.