http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947
Owen Leonard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #26428|0 |1 is obsolete| | --- Comment #23 from Owen Leonard <[email protected]> --- Created attachment 27035 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=27035&action=edit [SIGNED-OFF] 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 <[email protected]> Test plan confirms that the problem exists and that the patch corrects it. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
