]> git.koha-community.org Git - koha.git/commit
Bug 11947 - renumber reserves when hold is confirmed
authorRobin Sheat <robin@catalyst.net.nz>
Mon, 17 Mar 2014 05:33:00 +0000 (18:33 +1300)
committerGalen Charlton <gmc@esilibrary.com>
Tue, 15 Apr 2014 14:18:19 +0000 (14:18 +0000)
commit95056d17b715b74e3f7149d60e12d5a365d70eeb
tree4cfe28554019b73f8eb9e9c92431345da112d4c6
parentdcca71f0befa92d2212855aecfc0f473b6304832
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"

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Test plan confirms that the problem exists and that the patch corrects
it.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script, especially t/db_dependent/Reserves.t.
Improves priority calculation.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
C4/Reserves.pm
t/db_dependent/Reserves.t