[Bug 11947] New: Hold priorities not re-calculated when hold is confirmed on checkin.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Bug ID: 11947 Summary: Hold priorities not re-calculated when hold is confirmed on checkin. Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: bartonski@gmail.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com When checking an item which has multiple holds, clicking 'confirm hold' does notcause the priorities of the remaining reserves to be re-calculated. I started testing with the bib record for the book 'After Henry'. There were 3 items under this bib record. I created six test borrowers: +-----------+---------+------------+ | firstname | surname | cardnumber | +-----------+---------+------------+ | bws a | tester | bws000 | | bws b | tester | bws001 | | bws c | tester | bws003 | | bws d | tester | bws004 | | bws e | tester | bws005 | | bws f | tester | bws006 | +-----------+---------+------------+ I checked items out to the first three borrowers: +---------------+----------------+-----------+---------+------------+ | title | barcode | firstname | surname | cardnumber | +---------------+----------------+-----------+---------+------------+ | After Henry / | 00101000066353 | bws a | tester | bws000 | | After Henry / | ILEA000137401- | bws b | tester | bws001 | | After Henry / | 33080000109101 | bws c | tester | bws003 | +---------------+----------------+-----------+---------+------------+ I checked in the item with barcode '00101000066353' and clicked the 'Confirm hold' button. Checking reserves at this point, I saw the following: +-----------+---------+------------+----------+---------------+ | firstname | surname | cardnumber | priority | title | +-----------+---------+------------+----------+---------------+ | bws d | tester | bws004 | 0 | After Henry / | | bws e | tester | bws005 | 2 | After Henry / | | bws f | tester | bws006 | 3 | After Henry / | +-----------+---------+------------+----------+---------------+ Note that the priorities *should* be 0, 1, 2 at this point. when I check out to 'bws d tester', the priority 0 hold is removed, but the other two holds are not re-prioritized: +-----------+---------+------------+----------+---------------+ | firstname | surname | cardnumber | priority | title | +-----------+---------+------------+----------+---------------+ | bws e | tester | bws005 | 2 | After Henry / | | bws f | tester | bws006 | 3 | After Henry / | +-----------+---------+------------+----------+---------------+ When holds are displayed and the list does not start with priority 1, the holds display out of order, with holds showing at the bottom of the list with priority'1', even though there are no items with priority 1. See the attached screenshot'Screenshot from 2014-03-14 11-37-13.png', which was taken immediately after 'bws d tester' was checked in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #1 from Barton Chittenden <bartonski@gmail.com> --- Note that the holds were *Not* item level holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hbraum@nekls.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robin@catalyst.net.nz --- Comment #2 from Robin Sheat <robin@catalyst.net.nz> --- (In reply to Barton Chittenden from comment #0)
with priority'1', even though there are no items with priority 1. See the attached screenshot'Screenshot from 2014-03-14 11-37-13.png', which was taken immediately after 'bws d tester' was checked in.
The screenshot is missing, but I can probably just make my own. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |robin@catalyst.net.nz |ity.org | --- Comment #3 from Robin Sheat <robin@catalyst.net.nz> --- Adding some testing notes (I think there are some missing steps in your description). I issued the three items, and placed three non-item holds. The priorities were 1,2,3. I returned one of the items. I attempted to checkout that item to tester e (who did not have the first priority), but cancelled it (as it was waiting for tester d.) This caused the priorities to become 0,2,3 and the first reserve entry to change to having found=W and an itemnumber defined. This is probably because now there's a copy available. This seems correct overall, however the priorities should have been renumbered. I issued the item put aside for tester d to them. The reserve is removed, however the priorities are now 2,3 This causes the UI to show tester e at priority 2 (correct) and tester f at priority 1 (incorrect) which will cause them to change if the user hits "update holds". So essentially, bug is reproducible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #4 from Robin Sheat <robin@catalyst.net.nz> --- The priorities showing as '1' at the bottom is because of the UI not allowing for a priority greater than the number of holds, so it's forced to put it as the first. I have a patch that seems to work now. Just need to write up a test plan and attach it. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #5 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 26395 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26395&action=edit 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" -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #26395|0 |1 is obsolete| | --- Comment #6 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 26396 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26396&action=edit 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" [New version, including test case.] -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #7 from Heather Braum <hbraum@nekls.org> --- Created attachment 26416 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26416&action=edit Heather's Patch Testing for 11947 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #8 from Heather Braum <hbraum@nekls.org> --- After a patch was written for the community bug, it was applied to our test server this morning. I have tested it, and it does not resolve the issues. I'm attaching a PDF as it has screenshots, but here's the three tests, step-by-step that I did. TEST #1: 1. Created new record with 20 items. 2. Placed 7 holds on the record. 3. Checked one item in. 4. Triggered a hold for patron with priority 1. 5. Clicked Confirm hold. 6. Checked reserves.pl page and database priority entries. 7. Priorities are still 2-7 after Waiting status. 8. Clicked Update hold(s) button on reserves.pl and priorities are now 1-6. 9. Now the priorities are in order. TEST #2: 1. Put more holds on the record created above. 2. Checked 3 more items in and confirmed the holds. 3. The holds priorities are now 4-9. 4. Click update hold(s) button, and the holds are again 1-6 priority. Test #3 1. I checked two more items in and confirmed the holds. 2. I checked out three of the waiting items. 3. The reserves.pl and database output showed 3-6 priority for holds. 4. I added an additional hold to the record. 5. It was given priority 7. 7. I clicked Update Holds, and the latest hold was put as #3 priority!! Not priority 5, as expected. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #9 from Heather Braum <hbraum@nekls.org> --- The holds suddenly going out of order on an update without explanation is the most disconcerting part about this bug. (Especially when you have over 100 holds pending on a record across several months, and people at the bottom get moved to the top!). -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #26396|0 |1 is obsolete| | --- Comment #10 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 26427 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26427&action=edit 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" [New version, including test case.] -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #26427|0 |1 is obsolete| | --- Comment #11 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 26428 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26428&action=edit 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" -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #12 from Robin Sheat <robin@catalyst.net.nz> --- Created attachment 26429 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26429&action=edit Testing procedure illustrating the effects of the patch. I've attached a document with screenshots following the other attachment, however mine shows everything working as it should. I suspect that the patch wasn't applied correctly for testing. I've also rebased the patch against current master and attached that, there's no functional change (but API changes needed a tweak to the test case.) Note that this version is for master, I think I wrote the older one against 3.14 by accident. If applying to 3.14 there will probably be conflicts in the test case, but the actual fix is the same. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Robin Sheat <robin@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Just a guess, but I see that NEKLS is on 3.14.3 and there were a lot of patches for some priority issues on deleting/cancelling holds in 3.14.4 (bug 11336) - could this make a difference? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #14 from Robin Sheat <robin@catalyst.net.nz> --- (In reply to Katrin Fischer from comment #13)
Just a guess, but I see that NEKLS is on 3.14.3 and there were a lot of patches for some priority issues on deleting/cancelling holds in 3.14.4 (bug 11336) - could this make a difference?
It shouldn't, the first time I did it, I did it on 3.14.something by accident, rather than master. All it's doing is catching when a hold is marked as waiting, and recomputing the priorities for the rest of them. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #15 from Heather Braum <hbraum@nekls.org> --- Robin, I'm in the process of testing again on our test system and will do the real test now on our production server shortly after the patch is applied there. Did you write the patch for only when a hold is marked as waiting? What about when the hold gets marked as in transit? Did you cover that status too in your patch? Because I'm still seeing some priority status numbering going off on new holds if an existing hold is already marked as in transit and a new hold is added to the record. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #16 from Robin Sheat <robin@catalyst.net.nz> --- (In reply to Heather Braum from comment #15)
Did you write the patch for only when a hold is marked as waiting? What about when the hold gets marked as in transit? Did you cover that status too in your patch?
Because I'm still seeing some priority status numbering going off on new holds if an existing hold is already marked as in transit and a new hold is added to the record.
These are different cases than the one addressed here. It's possible that some of them are also fixed if the code happens to take the same path, but I wouldn't rely on it. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #17 from Heather Braum <hbraum@nekls.org> --- 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" This patch works as expected. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #18 from Heather Braum <hbraum@nekls.org> --- Robin, I filed a separate bug report, #11956, for the in transit issue I'm still seeing with holds priorities. Thanks for your help on starting to unravel this bug. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #19 from Robin Sheat <robin@catalyst.net.nz> --- (In reply to Robin Sheat from comment #14)
(In reply to Katrin Fischer from comment #13)
Just a guess, but I see that NEKLS is on 3.14.3 and there were a lot of patches for some priority issues on deleting/cancelling holds in 3.14.4 (bug 11336) - could this make a difference?
It shouldn't, the first time I did it, I did it on 3.14.something by accident, rather than master. All it's doing is catching when a hold is marked as waiting, and recomputing the priorities for the rest of them.
Turned out you were totally right there Katrin, btw. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #20 from Robin Sheat <robin@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.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #21 from Robin Sheat <robin@catalyst.net.nz> --- I added a version specifically for 3.14.4+ too, the only difference is in the test case. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff CC| |kyle@bywatersolutions.com --- Comment #22 from Kyle M Hall <kyle@bywatersolutions.com> --- These patches do not appear to be signed off. Changed status to "Needs Signoff". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Patch complexity|Trivial patch |Small patch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #26428|0 |1 is obsolete| | --- Comment #23 from Owen Leonard <oleonard@myacpl.org> --- 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 <oleonard@myacpl.org> 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.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.14 |master -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #24 from Galen Charlton <gmcharlt@gmail.com> --- The bug itself appears to be a regression caused by the patch for bug 9394. Specifically, the checkin sequence for circ/returns.pl does this: - ModReserveAffect(), which prior to Robin's proposed patch did not alter the priorities of other holds, just the one whose item is being set to waiting followed by - GetOtherReserves(), which among its many side-effects did fix up the rest of the priorities, via a call to ModReserveMinusPriority, which in turn called _FixPriority. However, this got broken because ModReserveMinusPriority now wants a reserve_id to identify the request being changed, but CheckReserves doesn't provide one, because _Findgroupreserve was never updated to provide reserve_id in every situation. *whew* CheckReserve and _Findgroupreserve failing to provide a reserve_id is a bug, but I think a separate one. Upshot: not to preempt QA, but I think Robin's patch is on the right track. However, it's time to take a hard look at GetOtherReserves, which is used only by circ/returns.pl, and see if it is time for that routine to go. At the very, very least, it need a name other than "GetOtherReserves". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #25 from Galen Charlton <gmcharlt@gmail.com> --- Bumping up priority -- issues that mangle the priority of hold requests can make life difficult at the circ desk. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #26 from Galen Charlton <gmcharlt@gmail.com> --- See also bug 12079. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 paxed <pasi.kallinen@pttk.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pasi.kallinen@pttk.fi --- Comment #27 from paxed <pasi.kallinen@pttk.fi> --- See also bug 12085 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |12086 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #27035|0 |1 is obsolete| | --- Comment #28 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 27122 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=27122&action=edit [PASSED QA] 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 --- Comment #29 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think I found another bug here: 1) Appply patch 2) Check out item 3) Place 3 holds, for patron a, b, c 4) Return the item - item is now waiting for a, b = 1, c = 2 5) Check out the book to b(!), revert waiting status as offered You will end up with: a = 1, c = 1, but in the database it's kind of more correct: a = 1, c = 3 I have put this on another bug - bug 12086. Still passing this as this patch just used an existing routine and I believe it's an improvement. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #30 from Galen Charlton <gmcharlt@gmail.com> --- Pushed to master. Thanks, Robin! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Joel Sasse <jsasse@plumcreeklibrary.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsasse@plumcreeklibrary.net -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11947 Fridolin SOMERS <fridolyn.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable CC| |fridolyn.somers@biblibre.co | |m --- Comment #31 from Fridolin SOMERS <fridolyn.somers@biblibre.com> --- Pushed to 3.14.x, will be in 3.14.10 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org