OU setting needed for default pickup location for staff placed holds

[Michele Morgan]

The fix for bug 1167541 changed how the pickup location is selected for staff placed holds.

Prior to 2.12, pickup location was set to the Home Library of the Staff User if the patron's preferred pickup location was not set.

In 2.12, pickup location is set to the Home Library of the Patron if the patron's preferred pickup location is not set.

The 2.12 behavior does not work well in all consortia. In ours, all staff users have a staff login separate from their patron account. The home library of the staff login is set to the library in which they work.

Patrons on the other hand move around among our libraries and their home library does not necessarily reflect any of the libraries they visit.

When a patron asks a staff member to place a hold on their behalf, it's assumed the patron wishes to pick up the hold at the staff member's library unless the patron interaction indicates otherwise.

The solution to 1167541 proposed by Jeff Godin looks to cover all the bases, providing an option to use the staff user's workstation or patron's home library when the patron has no preferred pickup location:

https://bugs.launchpad.net/evergreen/+bug/1167541/comments/13

We have reverted to the pre 2.12 behavior, but this needs a permanent fix that works across the board.

[Jessica Woolford (jwoolford)]

We will be reverting back to pre 2.12 behavior also. I agree that this needs a better fix to handle other workflows.

[Jeanette Lundgren (jlundgren)]

C/W MARS has also reverted back to the previous behavior. The 2.12 change had a negative impact on our libraries workflow and created some issues for patrons whose holds went to the wrong pickup library.

We are in support of creating an option to set the default behavior.

[Scott Thomas (scott-thomas-9)]

PaILS also feels this change is problematic. We would like a Library Setting that determines whether Workstation Library or the patron's Home Library is used as the default Pickup Library in the staff client.

[Mike Rylander (mrylander)]

Regarding the plan Jeff describes behind the link in the OP, I think the order for Configuration B should instead be

 1) Patrons's default pickup lib setting
 2) Workstation OU

That is, if the patron has a setting, it should be respected. Failing that, we'd add a YAOUS to decide whether workstation OU (with setting enabled) or patron home OU (code today; also, with setting disabled) is used.

[Kathy Lussier (klussier)]

I disagree with that order. If a patron is calling or walking into a specific library to ask staff to place a hold on their behalf, in most cases, I think they would expect to pick up their hold at that same library. In many cases, they may not even remember that they had set a default. I'm sure there are cases where a patron is calling another library because their own library is closed, but I would think that's the minority of staff-placed holds for our libraries.

Jeff's proposed setting wasn't to set a default in absence of a default pickup library being set. His setting was to override or not override that default when a staff hold is placed.

From everything I've heard from our folks, Jeff's proposed solution is still our preference. Michele and Jeanette - please chime in if I'm wrong on this!

[Kathy Lussier (klussier)]

As a corollary to this position, if I'm shopping on Best Buy's web site, I set the store in my hometown as my preferred store to check for item availability. If I order the item online with in-store pickup, it defaults to this store. However, if I personally visit the Best Buy one town over and special order something there, I wouldn't expect it to be delivered to what I have designated as my preferred store unless I specifically asked them to ship it there.

[Michele Morgan (mmorgan)]

Just echoing Kathy's comment that when a patron is interacting with a staff member at a certain library to place a hold, it's natural for them to assume they will be picking it up at that library. In our experience, it's unlikely that the patron would expect to pick it up at a different location without mentioning that in the conversation with the staff member.

[Mike Rylander (mrylander)]

Since there is consensus (at least here on the bug), how about we provide an org setting to specify a non-default behavior of "respect the patron's user setting, or the workstation org if that's not set"? The default behavior will then be to use the workstation org unit as the pre-selected pickup location. Libraries wanting to default to the patron's selected default can then actively switch to that, but without action, the consensus here is used.

Sound good?

Thank you both for your input!

[Terran McCanna (tmccanna)]

+1 to YAOUS

[Kathy Lussier (klussier)]

In your proposed behavior, then, Mike, what would happen for libraries wanting to default to the patron's selected default if they don't have a default. Would it then default to home library?

I hesitate to suggest it, but are two distinct YAOUS beneficial here?
 - one setting to determine whether staff-placed holds should respect the patron's default
 - a second setting to determine if workstation library or patron home library should be used if a) the first setting does NOT respect the patron's default or b) the patron has not set a default pickup library.

I know we try to limit settings, but the two in combination seem like they would cover all possible use cases.

[Michele Morgan (mmorgan)]

Another possibility would be a single org unit setting that can take multiple values, something like:

["staff_workstation"] - always default to the staff workstation
["patron_preference", "staff_workstation"] - use the patron preference if it exists, otherwise the staff workstation
["patron_preference", "patron_home_ou"] - use the patron preference, if it exists, otherwise the patron's home library

[Jason Boyer (jboyer)]

I don't like that first option at all. If you give patrons the option of setting a preferred pickup library and it never works that's no good. Better to only allow this OUS to choose between options 2 and 3 and if a patron has a preferred pickup lib that's always the default.

[Kathy Lussier (klussier)]

I wouldn't say it never works. It works for the patron when they are placing holds through the public catalog.

A consortium that does not want their libraries to choose option 1 can configure the setting at the consortium level and not give their libraries permission to change that setting. However, we do have consortia that want this setting to default to the staff workstation for staff-placed holds for the reasons described in comments 5, 6 and 7. I don't see why the software should restrict those Evergreen sites from making that choice.

[Jason Stephenson (jstephenson)]

I think it should default to the workstation ou, and staff should just know to ask if the patron wants to pick it up somewhere else. When staff are placing a hold for the patron, I think the patron's preferences should be thrown out the window on the assumption that the patron has contacted the place where they want to pick up the item.

No setting is required. This was the behavior before. It is a simple code change to revert back to the original behavior.

[Mike Rylander (mrylander)]

Kathy, I'm fine with multiple settings if that's the final consensus. I would prefer a simple setting to a compound setting, but the folks at PINES might need to weigh in since they prefer the "patron home library" default (how the code is right this moment) and that would require yet another simple setting.

To clarify, the behavior would be "workstation org unit" in my proposal if the user didn't have a preference but the library wanted to honor it generally.That's based on the premise that if a patron calls a specific location they certainly want to pick up the item there. I'm not sure I buy that, as they may have their home library's phone number in their contact list (or there may be a phone number for the main library in a system listed on the system's web site) and that's just the number they have at hand. IOW, I'm not entirely sold on the idea that the phone number a patron called correlates with the location they want to visit in even most cases, but I'm also not going to go against the consensus on this bug (and didn't intend to on the other, but here we are...).

Jason, IIUC, the previous behavior that was complained about in bug 1167541 was that it used the staff user's home library. That was definitely a bug (think: staff that float, or that use individual accounts and have their home at a location other than where they work). The "fix" was to use the patron's home library, but that's why we have this bug entry. The better fix (if we don't want any settings) would have been to just use workstation org, I agree. My proposal is, IIUC, to do what you want (use workstation org) unless 1) the patron has a pref AND 2) the library wants to honor that by default, with a setting.

[Kathy Lussier (klussier)]

Thanks for the explanation Mike. I'm okay with your initial proposal then since either would ultimately use the workstation library, which is what our general preference is here. But, yes, it would be good to hear if others want patron home library to be part of the mix.

[Terran McCanna (tmccanna)]

The current workflow is currently working fine for PINES, so I'm not in favor of any changes that force us into a new workflow without any option to retain our current workflow.

1) If patron has default pickup library, system defaults to that.
2) If patron has no default pickup library, system defaults to their home library.
3) If what the system defaults to doesn't match current library, staff asks if they'd like the current library to be their pickup library for this hold and if they'd like to change their default for future holds.

To take this conversation sideways, instead of having new default settings, what I'd *really* like to see happen would be if a pickup library was chosen that differed from the default, a prompt would then ask if the default should be updated. This would be handy in both the staff interface and in the OPAC.

[Jason Stephenson (jstephenson)]

As has been clarified in IRC, my preference is for workstation ou, not staff home ou. I always considered that a bug, but when you use generic circ accounts with the home ou set to the library where they work, you don't notice it.

Since I know I can't get my actual preference, I think the simpler the solution, the better.

I'd suggest a setting to use either workstation ou or patron home ou in the absence of a patron preferred pickup library.

And, that's all I have to say about that. Honest.

[Kathy Lussier (klussier)]

If patron home OU is desired (which it sounds like it is), my vote is for the setting described by mmorgan in comment #11. And, that's all I have to say about that. :)

[Cesar V (cesardv)]

A branch for the the those YAOUS's is here, along with changes to client JS to apply them:

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

[Jason Stephenson (jstephenson)]

/me will test!

[Dan Wells (dbw2)]

We had some reported problems related to this behavior change just yesterday, so I'm interested in seeing how this plays out.

So, I've looked at the posted branch all squinty-like for a number of minutes, and as far as I can tell, both options do the exact same thing. Perhaps I am missing something, of course, but as I read it, both just allow the staff ou to optionally clobber the preferred/home ou.

I think we need just the one option (either one), which gives you the two behaviors:
1) The "new" behavior (default to preferred location, then user home location if unset)
2) The (fixed) "old" behavior (default to staff workstation ou)

Is anyone actually needing or advocating for the "middle" option, which I believe is (preferred location, then staff ou if unset)? I don't want to rule that out if someone actually needs it, but I don't think the current branch does that, and we can always meet the pressing need now, then add that option later if people miss it.

[Dan Wells (dbw2)]

Okay, read everything again, and I do see folks advocating for the "middle" option. I guess I still feel if we want this confined to a bugfix, we should add the one option now to restore the tweaked old behavior, then add the potential second option as a feature down the road. This is just my opinion as another library which needs the old behavior.

[Kathy Lussier (klussier)]

+1 from me

[Jason Stephenson (jstephenson)]

I don't think a middle way is necessary.

I now think patron preferred ou should always be used if set, then the setting can control whether patron home ou or staff work ou is used in the absence of patron preferred ou.

We should keep it simple.

[Dan Wells (dbw2)]

Okay, I am a bit confused. What I described as the "middle" way is what Jason is actually describing as what he wants, that is (preferred pickup first, then staff ou).

Did the old behavior honor the preferred pickup location? If so, let's do that, if not, that should wait for a feature change, IMHO. Does anyone know with certainty? If not, I can start looking through the history.

In short, I think whatever we do at this late stage should optionally restore the old behavior, whatever that was (with the obvious fix for staff ws ou instead of staff user home ou).

[Dan Wells (dbw2)]

Initial looking seems to indicate preferred pickup library has been honored since before the most recent change. Sorry for any confusion added by the way I described the options. I believe the setting, if it is restoring lost behavior, should be exactly as Jason describes:

"patron preferred ou should always be used if set, then the setting can control whether patron home ou or staff work ou is used in the absence of patron preferred ou"

Is this right?

[Kathy Lussier (klussier)]

Looking at bug 1167541, I agree that the system always honored the preferred pickup library, if set. If that's what's needed to make it a bug fix and eligible for 3.1, I'm good with that.

Having said that, I will file a follow-up Wishlist bug to allow the system to override the preferred pickup library as this is the behavior that has been requested by our circ people.

[Jason Stephenson (jstephenson)]

Maybe I was confused. I understood the "middle way" to be more complicated and require more settings.

I believe your understanding of what I most recently said is correct, Dan.

I think 1 setting should do it to handle the case where a patron does not have a preferred pickup ou and staff are placing the hold. What happens in the absence of this new setting doesn't matter much.

[Dan Wells (dbw2)]

For your consideration, here is a branch which scales back Cesar's work to a more basic version to only optionally restore the old behavior:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp1699838_YAOUS_for_default_hold_pickup_loc

working/collab/dbwells/lp1699838_YAOUS_for_default_hold_pickup_loc

[Kathy Lussier (klussier)]

Works as advertised! Thanks Dan!

I merged the branch to master for inclusion in 3.1. Although we are calling it a bug fix, with the new OUS giving libraries a new option, I'll leave it up to the 3.0 maintainer to determine if it should be backported any further.

[Kathy Lussier (klussier)]

Oops! I forgot to send thanks to Cesar too. Thank you Cesar and everyone else who contributed to the discussion!

[Scott Thomas (scott-thomas-9)]

PaILS contracted with EOLI to fix this. They applied Cesar's patch as described in comment #20, and it is now present on our production system. The following were added to Library Settings:

"Honor the patron-preferred Pickup Library as the default for staff-placed holds" We set this to False at the consortium level.

"During Staff-placed holds, use the patron-preferred location or their home OU instead of the Staff User Workstation Org. unit as default pickup location." We set this to False at the consortium level.

This has resulted in what is, for us, the desired behavior: any time a staff member places a hold for a patron, the hold pickup OU will default to the staff workstation OU regardless of any patron-set hold pickup preference.

Thank you for everyone who worked on this.

[Kathy Lussier (klussier)]

Thanks for the feedback Scott! Just as an FYI, Cesar's patch is not the one that made it into the 3.1 release, as it was seen as an enhancement rather than a bug fix, and we were already past the enhancement phase for 3.1.

However, your comment serves as a reminder that I promised to file a Wishlist bug to cover the preference as to whether the system should honor the patron's preferred pickup lib or not.

[Kathy Lussier (klussier)]

bug 1759382