Pickup library defaults to Home OU of staff, instead of patron when placing holds

[Michael Peters]

Evergreen 2.3.4 (TPAC OPAC forced)
Postgres 9.1.8
Ubuntu 12.04
OpenSRF 2.1.2

When staff attempt placing a hold on behalf of a patron via the "Holds" tab in the patron account, the "Pickup Location" defaults to the home library of the currently logged in staff member, not the home library of the patron.

When the patron has set their pickup library preference, this isn't a problem, but when placing holds for users who haven't yet configured this setting this strange default is troublesome.

This is easily tested by attempting to place a hold for a patron who's home ou is different than that of the currently logged in staff member. You'll notice the default pickup location is the home ou of the staff member, not of the patron.

[Ben Shum (bshum)]

This doesn't seem to occur in master for our production environment, so I'm guessing that all the changes that were made to place hold recently for 2.4 might have changed how the lookup occurs and setting various options.

Marking as affecting 2.3 presently, but needs further testing by someone on 2.3 to confirm.

[Rogan Hamby (rogan-hamby)]

I have documented this issue in SCLENDS' 2.4RC production system. I've tested extensively and narrowed this to same conclusion as Michael's. It also affects the default scope of searching.

[Kathy Lussier (klussier)]

Hey Rogan,

Just a note that, by default, the tpac's scope in the staff client does default to the logged-in users preferred library. However, as of 2.4, this default can be changed via Admin → Workstation Administration → Set Search Preferences.

[Ben Shum (bshum)]

I see now what you guys are talking about... affects patrons who do *not* have a default pickup library defined yet as a library setting. This seems to occur for me in any place hold interface where a staff member can enter the pickup for a patron and not just the one specified.

My guess is that somewhere in Open-ILS/web/js/ui/default/opac/staff.js we have to define something that says use the home library of the patron if they don't have a library setting to make the switchover on staff_hold_usr_barcode_changed.

Marking bug as confirmed for 2.3 and 2.4 for the moment while we ponder a fix.

[Rogan Hamby (rogan-hamby)]

Thanks Kathy, I wasn't worried about that but it's good to know.

And yes Ben, that's exactly what we (I) see.

[Jason Etheridge (phasefx)]

I'm going to widen this a bit. Consider these scenarios:

admin user
     home lib = BR1
     email = admin_email
     daytime phone = admin_day_phone
     evening phone = admin_evening_phone
     other phone = admin_other_phone
     User setting, Default Phone Number = admin_default_phone
     User setting, Default SMS/Text Number = admin_default_sms
     User Setting, Default SMS/Text Carrier = Admin SMS Carrier (USA)
     User Setting, Default Hold Pickup Location = BR4
     User Setting, Hold Notification Format = Phone/Email/SMS

user u1
     home lib = BR3
     email = u1_email
     daytime phone = u1_day_phone
     evening phone = u1_evening_phone
     other phone = u1_other_phone
     No User Settings

user u2
     home lib = BR3
     email = u2_email
     daytime phone = u2_day_phone
     evening phone = u2_evening_phone
     other phone = u2_other_phone
     User setting, Default Phone Number = u2_default_phone
     User setting, Default SMS/Text Number = u2_default_sms
     User Setting, Default SMS/Text Carrier = U2 SMS Carrier (USA)
     User Setting, Default Hold Pickup Location = BR2
     User Setting, Hold Notification Format = Phone/Email/SMS

In the staff client, if the admin user goes to place a hold from within the admin account, we see:

     Pickup location: BR4

     Yes, by Email = checked
     Email Address: admin_email

     Yes, by Phone = checked
     Phone Number: admin_default_phone

     Yes, by Text Messaging = checked
     Mobile carrier: Admin SMS Carrier (USA) -- sometimes this new entry does not appear in the list and we get the Alaska carrier; need a new bug for that one
     Mobile number: admin_default_sms

If the admin user places a hold for u1 within their account, we see:

     Pickup location: BR4

     Yes, by Email = not checked
     Email Address: u1_email

     Yes, by Phone = not checked
     Phone Number: u1_day_phone

     Yes, by Text Messaging = not checked
     Mobile carrier: Admin SMS Carrier (USA) -- sometimes Alaska, same bug mentioned for admin
     Mobile number is blank

If the admin user places a hold for u2 within their account, we see:

     Pickup location: BR2

     Yes, by Email = checked
     Email Address: u2_email

     Yes, by Phone = checked
     Phone Number: u2_default_phone

     Yes, by Text Messaging = checked
     Mobile carrier: U2 SMS Carrier (USA)
     Mobile number: u2_default_sms

So I thought this was going to be worse than it was, but it looks like we're just getting pickup lib and mobile carrier from the staff user if there are no user settings.

[Jason Stephenson (jstephenson)]

Is this really a bug? I'd think if a patron walks into library A and asks them to place a hold, that the patron is likely to return to library A to pick it up and not to library B?

[Dawn Dale (ddale)]

It causes a great deal of extra work for staff. Many times the staff home library is not the library where the staff member works. If the staff member is logged in and all holds default to his/her home library that causes a lot of extra work. There are a number of reasons why the system should default to the patrons home library for pickup unless the patron changes that selection. So, is it a bug? Maybe not, but the current default does not behave in a way that is logical for library staff. The pickup library should be based on the patron information, not the staff information.

[Jason Etheridge (phasefx)]

Also considering staff placing holds for patrons over the phone.
Perhaps no defaults would be best for staff-placed holds for some
libraries if no user setting.

[Rogan Hamby (rogan-hamby)]

The phone scenario that Dawn mentioned is in fact the primary issue with SCLENDS libraries. We are primarily county systems where main or regional libraries may be open evenings, Saturdays or Sundays while others are closed. Thus, we end up with materials for rural patrons being delivered to far off urban libraries for pickup.

In a perfect world staff would always look and this would be a non-issue. So, this may not be a bug so much as undesired behavior where the alternative could prevent a common error.

[Jason Stephenson (jstephenson)]

Ah, so use the workstation OU, then. We don't have this issue, 'cause our staff insisted on generic accounts for circulation.

[Jason Stephenson (jstephenson)]

Actually, what I mean to say is that what will work for SC Lends will not work for us. This needs to have YAOUS so that the behavior can be toggled to use the patron OU or the workstation OU as the default.

[Jeff Godin (jgodin)]

In looking to see where this change in behavior was introduced, it seems to be a JSPAC vs TPAC difference.

I like the suggestion to use the workstation OU instead of the staff user's home_ou, and I don't see reason to keep the staff user's home_ou in the mix.

In the scenario where we are not overriding the default pickup library, I think that this order of preference works well:

* hold user's Default Pickup Library
* hold user's home_ou

In the case where we are overriding the default pickup library, I think that workstation OU should be sufficient.

An org unit setting to toggle the source of the default pickup library can determine if we override the user's defaults or not.

That org unit setting would toggle between the following two scenarios:

Configuration A (do not override user default pickup library for staff placed holds):

The default pickup library for staff-placed holds is the hold user's "default pickup library" user setting if set, otherwise the user's home_ou (which will always be set).

Configuration B (override user default pickup library for staff placed holds):

The default pickup library for staff-placed holds is the workstation OU, with belt-and-suspenders fallback to the two sources listed in Configuration A above.

For comparison, the current code implements what I'll call "Configuration X":

The default pickup library for staff-placed holds is the hold user's "default pickup library" user setting if set, otherwise the staff requestor's home_ou.

Some questions for interested parties while I work on a working branch:

Q1. Does anyone have a use case where an org unit setting is insufficient, and a workstation or a staff user setting would be desirable?

Q2. Does anyone object to removing staff user home_ou from consideration in favor of workstation OU?

Q3. Does anyone object to "Configuration X" above going away?

I won't wait for answers to these, but if you have a preference, please comment.

[Rogan Hamby (rogan-hamby)]

At least for SCLENDS the org unit setting you have proposed would work as Configuration A is our preferred behavior.

Q1. I could come up with some use case for this but it would be pretty esoteric. I'm not worried about it.

Q2. No objections.

Q3. No objections.

And thanks!

[Josh Stompro (u-launchpad-stompro-org)]

Hello, We just went live a week ago and this issue has been raising questions from staff.

We are a pair of consolidated system, so our staff move all over for training and just normal staffing needs. We are using per staff member logins that they use at any location they are at. So the current situation where the staff users home_ou gets set as the default is causing problems.

I like Jeffs proposed solution - I think we would use option A, Use either the Patrons preferred pickup lib if set or the Patrons home library.

It would also work to use the Workstation OU, but really there is no reason not to just use the patrons home_OU for our situation. I like that there could be an choice.

The few patrons that pickup items at a different branch can set their preferred pickup lib.

I will be happy to test and signoff.

Thanks
Josh

[Josh Stompro (u-launchpad-stompro-org)]

Hello, here is a branch that uses the staff users workstation ou for the default pickup lib instead of the staff users home ou.

user/stompro/lp1167541_use_ws_ou_default_hold_pickup
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1167541_use_ws_ou_default_hold_pickup

This isn't the full solution described by Jeff. I just needed something better than what the current behavior is for our use case.

We have per staff member logins, and we have staff that physically work a different branches. Currently when those staff are at a different branch, they constantly have to change the hold pickup location from their home lib depending on what location they are at. We don't do much centralized phone help, most of our patrons call their home library for help, so this is enough to fix the problem for us.

If a patron has a default hold pickup lib set, that does take precedence over the workstation ou.

I would rather use the patrons home_ou, but my perl is better than my javascript, so I went with this first.

Josh

[Josh Stompro (u-launchpad-stompro-org)]

We went live with this change over the weekend, and I heard from bmills saying they (SAGE) went live with it last week. I'm not adding a pull request tag because this is just a small part of the full solution.
Josh

[Mike Rylander (mrylander)]

The branch linked below falls back to the user's home org if they don't have the setting from up there -^ . It fixes both the web client and the xul client, but requires a new build and install of the staff client, AFAICT.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1167541_staff-hold-patron-pickuplib

[Chris Sharp (chrissharp123)]

Works for me! Signoff branch here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1167541_staff-hold-patron-pickuplib

[Galen Charlton (gmc)]

Removed 2.10 target as 2.10 is now security-only.

[Galen Charlton (gmc)]

Pushed to master, rel_2_12, and rel_2_11. Thanks, Mike and Chris!