[Koha-bugs] [Bug 14695] Add ability to place multiple item holds on a given record per patron

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14695

Benjamin Daeuber <bdaeuber at cityoffargo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdaeuber at cityoffargo.com

--- Comment #69 from Benjamin Daeuber <bdaeuber at cityoffargo.com> ---
We ran this through the sandbox and adjusted the test plan as follows:

a. We should probably update the test plan to make sure we’re all in the same
place:
        1. Patron class needs at least the same number of holds allowed as you
are going to allow per record
        2. Item level holds need to be enabled on the item type
b. Another note -- and this would vary by library – we adjusted the default for
holds on available items from “waiting” to “on hold” so they were not active
until they were checked in

That said, here’s what we noted:

1. If you start in the staff interface a patron can place holds on more than 3
items on a bib record, regardless of circ rules. But the behavior is kind of
strange. If holds are placed from the staff interface, it lets us place 4
holds. When a patron places holds from the OPAC it stops at 3, and then
prevents staff from placing additional holds in the staff interface.

2. Selecting an option from the drop down while “next available” is checked
places multiple holds on the selected item.

3. Related, the dropdown could cause policy enforcement issues for some
libraries. Say we allow users to put 10 items per record on hold (a realistic
number if you consider periodicals records that may have hundreds of items) and
a user selects it. If there is only 1 item, a patron could place it on hold 10
times and keep checking it out, bypassing renewal restrictions.

Some comments on the user experience

1. When you look at the holds queue, it’s not quite as expected. Say that a
Patron A puts 3 items on a bib record on hold, then Patron B comes along and
places 2 of the same items on that bib record on hold. Patron B will show up
4th and 5th in the hold queue, despite being 2nd for two different items.

2. I’m not sure that the drop down is necessary. If a customer wants to place
holds, the natural desire would be to either have checkboxes for each
individual item and a single hold button or individual hold buttons for each
item that would trigger a javascript confirmation rather than a second screen

3. Related, the user has to go back into the record for each item they want to
place on hold. This is cumbersome.

4. The actual workflow works more or less as expected. One issue would be when
checking out a second item on a bib record to a patron, there is a box that
asks to confirm checkout. I think we should have the option to suppress this.

-- 
You are receiving this mail because:
You are watching all bug changes.