Ability to Place Multiple Title/Metarecord Holds at Once

[Jason Stephenson]

Mainly for the benefit of book clubs or reading groups, staff and patrons should be able to place multiple holds for the same title or metarecord at one time. For example, if 5 copies of a title are required for a book group, then the staff or patron should be able to indicate that 5 copies are needed. Evergreen will process this request by placing 5 holds.

Staff may currently place multiple holds on behalf of a patron if the staff has the HOLD_EXISTS.override permission and the staff overrides the event for each hold. This process is tedious and requires staff intervention. This development proposes to streamline this process for staff and patrons.

The ability to use this feature will be controlled by a new permission and a new organizational unit setting. The permission, CREATE_DUPLICATE_HOLDS, will be used to control who can make use of this feature. The organizational unit setting, circ.holds.max_duplicate_holds, sets the limit for the maximum number of holds that a user may place for the same title or metarecord. It can also be used to disable the ability to place multiple holds at certain organizational units by being set to 0 or 1. This new setting will be unset by default.

When the requester has the permission at the current OPAC location, or working location in the staff client, and the maximum duplicate holds setting is set and greater than 1 for that same location, a select box will appear with numeric values from 1 to the value of the maximum duplicate holds setting or the number of available copies for this hold, whichever is lower. The user can change this value to indicate the number of holds to place.

This number field will not appear when placing holds for multiple different titles from a My List. Bug 1687319 and bug 1687321 should be resolved before adding this feature when placing holds for multiple titles. There are other factors in the implementation of multiple title holds placement that may complicate adding this feature to that interface, even after the open bugs are resolved.

The number field will be disabled or not display for part, volume, or copy holds. It may be confusing for patrons placing part or volume holds who may think that they are requesting different parts or volumes when the actual behavior would be to make multiple requests for the same part or volume. It also makes no sense to make multiple requests for a single copy.

When the user presses the Submit button to place the hold(s), they will be presented with a confirmation dialog that they intend to place X number of holds, if the number of holds to place is greater than 1. If the user continues, the current hold will be place X number of times in batch mode.

The back end holds code will also be modified to check that the requester has the appropriate permission and that the organizational unit is set correctly for the current organization. If the number of holds being placed, combined with any existing holds that may exist for the patron and current target, is lower than or equal to the value of the maximum duplicate holds setting, then hold placement will proceed as normal. If this number exceed the value of the setting, then the HOLD_EXISTS override permission will be required in order to continue.

[Mike Rylander (mrylander)]

It's great you're working on this, Jason. I have one question about functionality/workflow: will there be some mechanism linking the holds together, so that if the holds take significantly different amounts of time (thinking around the hold shelf expire time) to arrive the patron won't have to keep coming back or lose some of the holds? Something like a choice between "alert me when each arrives" and "alert me when all are available".

Thanks!

[Jason Stephenson (jstephenson)]

No, that wasn't part of the original specification, and I didn't think of it, either. Grouping the hold notifications is a good idea/good point to bring up as would be possibly extending the hold shelf time. To do that might require some kind of link among the holds beyond just that they have the same target and same patron.

Staff might also need some kind of alert that the hold being processed is part of a group of holds, and that it should be put aside until the rest of the copies arrive.

It also might be a good idea to the let the user specify a hold expiration date, like a not needed after date, when placing these holds. I'm not sure if that should be part of this or if it would be a good idea to expose the expiration date in a manner similar to what I proposed for the reactivate date for holds placed as suspended in bug 1189989.

[Kathy Lussier (klussier)]

Thanks for the suggestion Mike!

I really like the idea of grouping holds together, but I think it's a separate project from this one and deserves its own Wishlist bug.

Right now, our libraries are already placing these book club holds by placing each individual hold separately, clicking through the HOLD_EXISTS override, and then clicking to place the next hold. It's a fairly tedious process, and the intent of this project is to improve the workflow for placing these holds.

We generally haven't heard complaints about the fact that the holds are filled over the course of time. I don't know if it's because they all tend to arrive within a few days of each other or if it's for another reason. I'm going to add the idea to our development site to see if there is any interest in doing it as a future project.

Kathy

[Jason Stephenson (jstephenson)]

My branch is user/dyrcona/lp1694058_multiple_hold_placement in the working repository.

I believe Kathy Lussier is going to add a sign off branch, so I'll refrain from adding the pullrequest tag and allow Kathy to add it for her branch.

[Kathy Lussier (klussier)]

My signoff is available at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1694058_multiple_hold_placement_signoff

I'm not merging it for now in order to give others who were uninvolved in the project an opportunity to review the branch.

Thanks Jason!

[Kathy Lussier (klussier)]

It still looks good three months later! I added a release notes entry and merged the code to master for inclusion in release 3.1.

Thank you Jason!