Bugzilla – Attachment 26498 Details for
Bug 11947
Hold priorities not re-calculated when hold is confirmed on checkin.
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
Bug 11947 - [3.14.x] renumber reserves when hold is confirmed
Bug-11947---314x-renumber-reserves-when-hold-is-co.patch (text/plain), 3.99 KB, created by
Robin Sheat
on 2014-03-21 01:42:55 UTC
(
hide
)
Description:
Bug 11947 - [3.14.x] renumber reserves when hold is confirmed
Filename:
MIME Type:
Creator:
Robin Sheat
Created:
2014-03-21 01:42:55 UTC
Size:
3.99 KB
patch
obsolete
>From 0dc98f6762a77984b0820b275735f056bf8d0c81 Mon Sep 17 00:00:00 2001 >From: Robin Sheat <robin@catalyst.net.nz> >Date: Mon, 17 Mar 2014 18:33:00 +1300 >Subject: [PATCH] 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" >--- > C4/Reserves.pm | 2 +- > t/db_dependent/Reserves.t | 28 +++++++++++++++++++++++++++- > 2 files changed, 28 insertions(+), 2 deletions(-) > >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 ); > } >diff --git a/t/db_dependent/Reserves.t b/t/db_dependent/Reserves.t >index fe0baaa..3b81cbc 100755 >--- a/t/db_dependent/Reserves.t >+++ b/t/db_dependent/Reserves.t >@@ -2,7 +2,7 @@ > > use Modern::Perl; > >-use Test::More tests => 20; >+use Test::More tests => 23; > use MARC::Record; > use DateTime::Duration; > >@@ -191,6 +191,30 @@ my ($itemnum_cpl, $itemnum_fpl); > barcode => 'bug10272_FPL' > } , $bibnum2); > >+# Ensure that priorities are numbered correcly when a hold is moved to waiting >+# (bug 11947) >+$dbh->do("DELETE FROM reserves WHERE biblionumber=?",undef,($bibnum2)); >+AddReserve('RPL', $requesters{'RPL'}, $bibnum2, >+ $constraint, $bibitems, 1, $resdate, $expdate, $notes, >+ $title, $checkitem, $found); >+AddReserve('FPL', $requesters{'FPL'}, $bibnum2, >+ $constraint, $bibitems, 2, $resdate, $expdate, $notes, >+ $title, $checkitem, $found); >+AddReserve('CPL', $requesters{'CPL'}, $bibnum2, >+ $constraint, $bibitems, 3, $resdate, $expdate, $notes, >+ $title, $checkitem, $found); >+ModReserveAffect($itemnum_cpl, $requesters{'RPL'}, 0); >+ >+# Now it should have different priorities. >+my ($count, $title_reserves) = GetReservesFromBiblionumber($bibnum2); >+# Sort by reserve number in case the database gives us oddly ordered results >+my @reserves = sort { $a->{reserve_id} <=> $b->{reserve_id} } @$title_reserves; >+is($reserves[0]{priority}, 0, 'Item is correctly waiting'); >+is($reserves[1]{priority}, 1, 'Item is correctly priority 1'); >+is($reserves[2]{priority}, 2, 'Item is correctly priority 2'); >+ >+ >+$dbh->do("DELETE FROM reserves WHERE biblionumber=?",undef,($bibnum2)); > AddReserve('RPL', $requesters{'RPL'}, $bibnum2, > $constraint, $bibitems, 1, $resdate, $expdate, $notes, > $title, $checkitem, $found); >@@ -291,6 +315,8 @@ is( > my $letter = ReserveSlip('CPL', $requesters{'CPL'}, $bibnum); > ok(defined($letter), 'can successfully generate hold slip (bug 10949)'); > >+ >+ > $dbh->rollback; > > sub count_hold_print_messages { >-- >1.8.3.2
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
|
Splinter Review
Attachments on
bug 11947
:
26395
|
26396
|
26416
|
26427
|
26428
|
26429
| 26498 |
27035
|
27122