[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