Bug 2830 - Hold not removed when "trapped" item on hold shelf is checked out to a different patron in the holds queue
: Hold not removed when "trapped" item on hold shelf is checked out to a differ...
Status: NEW
Product: Koha
Hold requests
: rel_3_0
: All All
: P3 critical (vote)
Assigned To: Henri-Damien LAURENT
:
:
:
:
  Show dependency treegraph
 
Reported: 2008-11-28 08:20 UTC by Chris Cormack
Modified: 2010-07-08 08:22 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:56:55 UTC


---- Reported by bchurch@ptfs.com 2008-11-28 08:20:15 ----

Although it is not normal procedure, "trapped" items waiting on the hold are
sometimes checked out to a different patron in the holds queue. For example, a
"trapped" item is waiting on the hold shelf for Patron A. If this item is
checked out to Patron C who has hold priority #2, the hold for Patron C is not
removed from the holds queue. The hold for Patron C should be considered as
filled and removed from the holds queue.

Here are the steps for recreating this problem:
1. Place three holds on a title.
2. Check out an item to Patron A who has priority #1 so it is "trapped" for
Patron A. The hold status is "waiting".
3. Check out this "trapped" item to Patron C, who now has the #2 priority hold
in the holds queue.
4. Ignore the system message that the item is being held for Patron A and check
out the item to Patron C.
5. The hold for Patron A is re-inserted as priority #1 in the holds queue, but
the hold for Patron C is not removed from holds queue.



---- Additional Comments From bchurch@ptfs.com 2008-12-01 16:13:53 ----

Step 2 Should read "Check in" not "check out" an item.



---- Additional Comments From bchurch@ptfs.com 2008-12-02 09:38:09 ----

When the hold for Patron A is re-inserted in the holds queue, the hold becomes
a "copy specific" hold instead of an "any copy" hold. If you look at the normal
view for the title in the staff client, the item appears as being both checked
out to Patron C and on hold for Patron A.



---- Additional Comments From joe.atzberger@liblime.com 2009-01-27 11:26:20
----

Increased severity since this compromises holds as a feature.  Koha presents
the availability of adjusting queue priority, without any warning of the
negative behavior resulting from attempting it.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:56 UTC  ---

This bug was previously known as _bug_ 2830 at
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2830

Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here: chris@bigballofwax.co.nz.
   Previous reporter was bchurch@ptfs.com.
CC member 1goodlibrarian@gmail.com does not have an account here
CC member adrea@moablibrary.org does not have an account here
CC member arm@hanover.ca does not have an account here
CC member mjr@ttllp.co.uk does not have an account here