Created attachment 41048 [details] shows AU member is Priority #1 and NZ member in #2 position This is not the issue described in this bug: (2830 Hold not removed when "trapped" item on hold shelf is checked out to a different patron in the holds queue http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2830 / [Signed off] bug_2830: Remove reserve when checking out if the borrower is not the first one in the reserve queue (13.54 KB, patch) 2011-11-17 16:57 UTC, Liz Rea http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6329 ) It is a new “bug” that comes about, I believe, because we have an “invalid” reserves queue. We have a library in Australia and a library in New Zealand. We have merged our biblio records and commissioned work to make Koha differentiate between a reserve placed by an AU member and a reserve placed by a NZ member. They sit in the one reserve queue and are numbered 1,2,3 with the Pickup Library matched to where the member lives. The system knows to match AU book with AU member and same with NZ. All works perfectly fine when the reserve is known because the book is returned– this flags that a reserve is waiting and we confirm the reserve. The problem occurs because we have a new feature called the “Invalid Reserves Queue”. It is a report to show where a reserve is a mismatch, ie. An AU member reserves a NZ book and vice versa. So problem occurs when the reserve is found via the “Invalid Reserves Queue" then it behaves differently. If it is a NZ book we choose the next NZ member. However because they are not in Priority # 1 the reserve remains behind even though we have issued the book to them. So it is similar to these other bugs in that the checkout of the book does not remove the reserve because it is not in Priority No. 1 but it only happens if the reserve comes up via the Invalid queue as it works perfectly fine in all other circumstances. Hoping there are libraries that operate in this fashion and if so has anyone seen and resolved this issue?
I think the "'invalid' reserve queue' is a red herring since it's (I assume) a custom report and isn't related to the functionality of the holds system. However, I am able to reproduce this problem in master: 1. Find a title with multiple holds. 2. Check an available item out to any patron who is not at the top of the hold priority list. 3. The hold for that patron is not removed -- it's still on hold for them.
Ah, I can recreate, but only after build_holds_queue has been run and picked up the hold for the first patron
Owen and Nick, yes you are correct. This was a customisation - the creation of an "invalid reserves queue". The fix was - Catalyst made the Invalid RQ just a report - the queue had been assigning an item to fill a reserve, it now ignores that. And fills it with whatever item is issued to the borrower. That made the reserve come off. So I will close this bug. thanks for looking into it.
Reopening because this issue still exists: > 1. Find a title with multiple holds. > 2. Check an available item out to any patron who > is not at the top of the hold priority list. > 3. The hold for that patron is not removed -- it's > still on hold for them.
Hi Owen, I just checked this on master and can't replicate: 1) Find record 2) place holds for 2 different patrons (record level) 3) check out any item to the person last in the holds queue 4) Hold has been removed from the list / has been filled Does the problem still appear for you?
(In reply to Katrin Fischer from comment #5) Confirmed on master: 1) Find record 2) place record level holds for 2 different patrons (record level) 2.5) Run holds queue builder 3) check out the item queued for patronith priority 1 to the second 4) Hold has been removed from the list / has been filled CheckReserves seems to promise to return 'all reserves', however, it returns only a single hold from the holds queue if that has been built
Created attachment 91067 [details] [review] Bug 14549: Unit tests To test: 1 - Apply just this patch 2 - prove -v t/db_dependent/Reserves.t 3 - Failure 4 - Apply second patch 5 - prove -v t/db_dependent/Reserves.t 6 - Success!
Created attachment 91068 [details] [review] Bug 14549: Check patrons reserves for any holds on a bib when checking out an item MoveReserve uses CheckReserves to see if the current patron has any holds on the title they are checking out, however, CheckReserves doesn't return all holds on a biblio, it returns holds on the item from the holdsqueue if they exist This can create a condition where we check holds on an item, find we have it planned for another borrower, confirm checkout to the current borrower, but don't fill their hold To test: 1) Find record 2) place record level holds for 2 different patrons (record level) 3) Run holds queue builder, check the queue to confirm an item was selected for patron 1 Circulation->Holds queue->Library="All" 4) Check out the item queued for patron with priority 1 to the second patron 5) You should be asked to confirm, do so 6) Note the item checks out, but both holds remain 7) Apply patch 8) Check in the item 9) Don't confirm the hold 10) Check the holds on the record and the holds queue 11) Patron 1 should be priority 1 with an item selected from the holds queue 12) Checkout to patron 2 as before 13) Note the hold for patron 2 is filled this time 14) Prove -v t/db_dependent/Reserves.t
Created attachment 91069 [details] [review] Bug 14549: POD and variable cleanup
Created attachment 91776 [details] [review] Bug 14549: Unit tests To test: 1 - Apply just this patch 2 - prove -v t/db_dependent/Reserves.t 3 - Failure 4 - Apply second patch 5 - prove -v t/db_dependent/Reserves.t 6 - Success! Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 91777 [details] [review] Bug 14549: Check patrons reserves for any holds on a bib when checking out an item MoveReserve uses CheckReserves to see if the current patron has any holds on the title they are checking out, however, CheckReserves doesn't return all holds on a biblio, it returns holds on the item from the holdsqueue if they exist This can create a condition where we check holds on an item, find we have it planned for another borrower, confirm checkout to the current borrower, but don't fill their hold To test: 1) Find record 2) place record level holds for 2 different patrons (record level) 3) Run holds queue builder, check the queue to confirm an item was selected for patron 1 Circulation->Holds queue->Library="All" 4) Check out the item queued for patron with priority 1 to the second patron 5) You should be asked to confirm, do so 6) Note the item checks out, but both holds remain 7) Apply patch 8) Check in the item 9) Don't confirm the hold 10) Check the holds on the record and the holds queue 11) Patron 1 should be priority 1 with an item selected from the holds queue 12) Checkout to patron 2 as before 13) Note the hold for patron 2 is filled this time 14) Prove -v t/db_dependent/Reserves.t Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 91778 [details] [review] Bug 14549: POD and variable cleanup Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 91941 [details] [review] Bug 14549: Unit tests To test: 1 - Apply just this patch 2 - prove -v t/db_dependent/Reserves.t 3 - Failure 4 - Apply second patch 5 - prove -v t/db_dependent/Reserves.t 6 - Success! Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 91942 [details] [review] Bug 14549: Check patrons reserves for any holds on a bib when checking out an item MoveReserve uses CheckReserves to see if the current patron has any holds on the title they are checking out, however, CheckReserves doesn't return all holds on a biblio, it returns holds on the item from the holdsqueue if they exist This can create a condition where we check holds on an item, find we have it planned for another borrower, confirm checkout to the current borrower, but don't fill their hold To test: 1) Find record 2) place record level holds for 2 different patrons (record level) 3) Run holds queue builder, check the queue to confirm an item was selected for patron 1 Circulation->Holds queue->Library="All" 4) Check out the item queued for patron with priority 1 to the second patron 5) You should be asked to confirm, do so 6) Note the item checks out, but both holds remain 7) Apply patch 8) Check in the item 9) Don't confirm the hold 10) Check the holds on the record and the holds queue 11) Patron 1 should be priority 1 with an item selected from the holds queue 12) Checkout to patron 2 as before 13) Note the hold for patron 2 is filled this time 14) Prove -v t/db_dependent/Reserves.t Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 91943 [details] [review] Bug 14549: POD and variable cleanup Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Nice work! Pushed to master for 19.11.00
Pushed to 19.05.x for 19.05.03