[Koha-bugs] [Bug 11947] Hold priorities not re-calculated when hold is confirmed on checkin.

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Mar 21 02:42:55 CET 2014


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947

--- Comment #20 from Robin Sheat <robin at catalyst.net.nz> ---
Created attachment 26498
  -->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26498&action=edit
Bug 11947 - [3.14.x] renumber reserves when hold is confirmed

Currently when a reserve is moved to "waiting" status because it's
acknowledged on checkin, the reserve priorities aren't renumbered. This
causes things to go a bit haywire in the UI, in particular, some
reserves can unjustly end up with priority 1 when they shouldn't. It
also seemed to mess with the logic of who should get it next, but I
didn't look too closely at that.

This patch forces a renumbering so that all the priorities remain
copacetic.

Test plan:
* have a few borrowers, say 4.
* have a biblio with a single item (you can scale this up, it should
  work just the same.)
* issue the item to borrower A
* have borrowers B, C, and D place a hold on the item
* return the item, acknowledge that it'll be put aside for B.
* view the holds on the item.
Without the patch:
* the hold priorities in the UI end up being "waiting, 2, 1" when they
  should be "waiting, 1, 2".
* in the database "reserves" table, they're really "0, 2, 3" when they
  should be "0, 1, 2".
With the patch:
* the hold priorities in the UI end up being "waiting, 1, 2"
* in the database, they're "0, 1, 2"

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


More information about the Koha-bugs mailing list