From 99af2468958833b1506cf59976c71be2f2827fa6 Mon Sep 17 00:00:00 2001 From: Robin Sheat Date: Mon, 17 Mar 2014 18:33:00 +1300 Subject: [PATCH] Bug 11947 - 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" --- C4/Reserves.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/C4/Reserves.pm b/C4/Reserves.pm index 689f34d..8f37590 100644 --- a/C4/Reserves.pm +++ b/C4/Reserves.pm @@ -1274,7 +1274,7 @@ sub ModReserveAffect { $sth = $dbh->prepare($query); $sth->execute( $itemnumber, $borrowernumber,$biblionumber); _koha_notify_reserve( $itemnumber, $borrowernumber, $biblionumber ) if ( !$transferToDo && !$already_on_shelf ); - + _FixPriority( { biblionumber => $biblionumber } ); if ( C4::Context->preference("ReturnToShelvingCart") ) { CartToShelf( $itemnumber ); } -- 1.8.3.2