[Bug 25969] New: Checking in a found hold at a different branch then confirming the hold causes internal server error
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Bug ID: 25969 Summary: Checking in a found hold at a different branch then confirming the hold causes internal server error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: kyle@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, AddReturn() calls RevertWaitingStatus(), which unsets found, and itemnumber ( if the hold was record level ). AddReturn() then retuns the message 'ResFound', which triggers the hold fulfillment dialog, which passes the reserve_id back to circulation.pl. Then, circulation.pl attempts to get the biblio via the itemnumber, which the hold doesn't have, causing an ISE. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- So the root cause is that we are not passing the itemnumber *for the scanned barcode* back to the form, making itemnumber undef, so the Item object is empty, so calling the biblio method causes an ISE. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 106758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106758&action=edit Bug 25969: Checking in a found hold at a different branch then confirming the hold causes internal server error If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, and an attempt is made to re-fill the hold with the item, Koha will return an ISE. Test Plan: 1) Place a hold for Library A, at Library A, for pickup at Library A 2) Check in the item at Library A and fill the hold so it is waiting at Library A 3) Log in as Library B, check in the same barcode 4) Note the request to fill the hold with the item 5) Choose to fill the hold 6) Note you get an internal server error 7) Apply this patch 8) Restart all the things! 9) Repeat steps 1-5 10) No ISE! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106758|0 |1 is obsolete| | --- Comment #3 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 106771 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106771&action=edit Bug 25969: Checking in a found hold at a different branch then confirming the hold causes internal server error If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, and an attempt is made to re-fill the hold with the item, Koha will return an ISE. Test Plan: 1) Place a hold for Library A, at Library A, for pickup at Library A 2) Check in the item at Library A and fill the hold so it is waiting at Library A 3) Log in as Library B, check in the same barcode 4) Note the request to fill the hold with the item 5) Choose to fill the hold 6) Note you get an internal server error 7) Apply this patch 8) Restart all the things! 9) Repeat steps 1-5 10) No ISE! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com Status|Needs Signoff |Failed QA --- Comment #4 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I'm still getting an error with the patch applied. "Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 148" -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #106771|0 |1 is obsolete| | --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 107697 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=107697&action=edit Bug 25969: Checking in a found hold at a different branch then confirming the hold causes internal server error If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, and an attempt is made to re-fill the hold with the item, Koha will return an ISE. Test Plan: 1) Place a hold for Library A, at Library A, for pickup at Library A 2) Check in the item at Library A and fill the hold so it is waiting at Library A 3) Log in as Library B, check in the same barcode 4) Note the request to fill the hold with the item 5) Choose to fill the hold 6) Note you get an internal server error 7) Apply this patch 8) Restart all the things! 9) Repeat steps 1-5 10) No ISE! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Sally <sally.healey@cheshiresharedservices.gov.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA CC| |sally.healey@cheshireshared | |services.gov.uk --- Comment #6 from Sally <sally.healey@cheshiresharedservices.gov.uk> --- This patch works if you check in using the the 'check in' function in the main search bar. However, if you use the check in at: cgi-bin/koha/circ/returns.pl - then you still get the same ISE as before the patch is applied: Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 148 in (eval) at /kohadevbox/koha/circ/returns.pl line 148 145: my $cancel_reserve = $query->pa -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff CC| |nick@bywatersolutions.com --- Comment #7 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Sally from comment #6)
This patch works if you check in using the the 'check in' function in the main search bar.
However, if you use the check in at: cgi-bin/koha/circ/returns.pl - then you still get the same ISE as before the patch is applied:
Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 148 in (eval) at /kohadevbox/koha/circ/returns.pl line 148 145: my $cancel_reserve = $query->pa
I cannot recreate this, can you test again and explain the steps? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #8 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I'm also getting an error. To recreate: - Log in at Library A - Place hold on item at Library A, for pickup at Library A - Check item in at Library A - Click "Confirm hold" - Set library to Library B - Check item in again - Click "Confirm hold and transfer" - get error: Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 147 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26386 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #9 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 109678 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109678&action=edit Bug 25969: Don't set itemnumber as reserve->itemnumber When a hold is checked in at the wrong destination we revert the found status For a title level hold this means we return it to a title level hold, with no itemnumber When we checkin the item we find the hold, but won't set the itemnumber in the hold until it is confirmed In the script we were setting the itemnumber param, but then setting it again using the reserve itemnumber. In all conditions before the itemnumber has been set, we don't need to set it again, especially when we do so incorrectly To test: - Log in at Library A - Place hold on item at Library A, for pickup at Library A - Check item in at Library A - Click "Confirm hold" - Set library to Library B - Check item in again (try with both the box on reutrns.pl and the box in the header) - Click "Confirm hold and transfer" - get error: Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 147 - apply patch - repeat - success! - confirm trappings of holds works as normally otherwise too -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan.berndtsson@ub.gu.se --- Comment #10 from Nick Clemens <nick@bywatersolutions.com> --- *** Bug 26386 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org Severity|normal |major -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #107697|0 |1 is obsolete| | --- Comment #11 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 109755 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109755&action=edit Bug 25969: Checking in a found hold at a different branch then confirming the hold causes internal server error If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, and an attempt is made to re-fill the hold with the item, Koha will return an ISE. Test Plan: 1) Place a hold for Library A, at Library A, for pickup at Library A 2) Check in the item at Library A and fill the hold so it is waiting at Library A 3) Log in as Library B, check in the same barcode 4) Note the request to fill the hold with the item 5) Choose to fill the hold 6) Note you get an internal server error 7) Apply this patch 8) Restart all the things! 9) Repeat steps 1-5 10) No ISE! Signed-off-by: Daniel Gaghan <daniel.gaghan@pueblolibrary.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109678|0 |1 is obsolete| | --- Comment #12 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 109756 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109756&action=edit Bug 25969: Don't set itemnumber as reserve->itemnumber When a hold is checked in at the wrong destination we revert the found status For a title level hold this means we return it to a title level hold, with no itemnumber When we checkin the item we find the hold, but won't set the itemnumber in the hold until it is confirmed In the script we were setting the itemnumber param, but then setting it again using the reserve itemnumber. In all conditions before the itemnumber has been set, we don't need to set it again, especially when we do so incorrectly To test: - Log in at Library A - Place hold on item at Library A, for pickup at Library A - Check item in at Library A - Click "Confirm hold" - Set library to Library B - Check item in again (try with both the box on reutrns.pl and the box in the header) - Click "Confirm hold and transfer" - get error: Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 147 - apply patch - repeat - success! - confirm trappings of holds works as normally otherwise too Signed-off-by: Daniel Gaghan <daniel.gaghan@pueblolibrary.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109755|0 |1 is obsolete| | --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 110006 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110006&action=edit Bug 25969: Checking in a found hold at a different branch then confirming the hold causes internal server error If a record level hold is filled and waiting at Library A, and the item is checked in at Library B, and an attempt is made to re-fill the hold with the item, Koha will return an ISE. Test Plan: 1) Place a hold for Library A, at Library A, for pickup at Library A 2) Check in the item at Library A and fill the hold so it is waiting at Library A 3) Log in as Library B, check in the same barcode 4) Note the request to fill the hold with the item 5) Choose to fill the hold 6) Note you get an internal server error 7) Apply this patch 8) Restart all the things! 9) Repeat steps 1-5 10) No ISE! Signed-off-by: Daniel Gaghan <daniel.gaghan@pueblolibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109756|0 |1 is obsolete| | --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 110007 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=110007&action=edit Bug 25969: Don't set itemnumber as reserve->itemnumber When a hold is checked in at the wrong destination we revert the found status For a title level hold this means we return it to a title level hold, with no itemnumber When we checkin the item we find the hold, but won't set the itemnumber in the hold until it is confirmed In the script we were setting the itemnumber param, but then setting it again using the reserve itemnumber. In all conditions before the itemnumber has been set, we don't need to set it again, especially when we do so incorrectly To test: - Log in at Library A - Place hold on item at Library A, for pickup at Library A - Check item in at Library A - Click "Confirm hold" - Set library to Library B - Check item in again (try with both the box on reutrns.pl and the box in the header) - Click "Confirm hold and transfer" - get error: Can't call method "biblio" on an undefined value at /kohadevbox/koha/circ/returns.pl line 147 - apply patch - repeat - success! - confirm trappings of holds works as normally otherwise too Signed-off-by: Daniel Gaghan <daniel.gaghan@pueblolibrary.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |26485 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26485 [Bug 26485] Simplify itemnumber handling in returns.pl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #15 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Kyle, Nick, I have a follow-up patches for this, but I prefer to not push it as a RM follow-up but separated instead. Can you have a look at bug 26485 please? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |20.11.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #16 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Pushed to master for 20.11, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joonas.kylmala@helsinki.fi --- Comment #17 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- The patch "Bug 25969: Don't set itemnumber as reserve->itemnumber" here breaks printing hold slip in returns.pl page if you try to print it more than once. So if you return the hold first once, it prints the slip fine and goes to waiting state, then if you check in the item another time and try to print the slip the Internal server error comes. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed --- Comment #18 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Joonas Kylmälä from comment #17)
The patch "Bug 25969: Don't set itemnumber as reserve->itemnumber" here breaks printing hold slip in returns.pl page if you try to print it more than once. So if you return the hold first once, it prints the slip fine and goes to waiting state, then if you check in the item another time and try to print the slip the Internal server error comes.
Nick or Kyle, can you have a look at this ASAP please? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #19 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 111328 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111328&action=edit Bug 25969: (follow-up) If not coming from hold modal find item by barcode -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #20 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Nick Clemens from comment #19)
Created attachment 111328 [details] [review] Bug 25969: (follow-up) If not coming from hold modal find item by barcode
This fixes the ISE, but if you click "Print slip and confirm" the modal launches again, and again, and again... Pinging Kyle -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #21 from Stefan Berndtsson <stefan.berndtsson@ub.gu.se> --- (In reply to Nick Clemens from comment #20)
(In reply to Nick Clemens from comment #19)
Created attachment 111328 [details] [review] [review] Bug 25969: (follow-up) If not coming from hold modal find item by barcode
This fixes the ISE, but if you click "Print slip and confirm" the modal launches again, and again, and again...
Pinging Kyle
That repeat is due to the change from Bug 25907 that adds the barcode to the modal request. This makes the system think there is another book being returned after the currently processed one. Since it's the same one it just keeps repeating. I tried commenting out the barcode part from 25907 and that works (when itemnumber is provided), but the functionality from 25907 of course stops working properly then. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26627 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |26627 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26627 [Bug 26627] Print and confirming a hold can cause an infinite loop -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #22 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 111344 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111344&action=edit Bug 26627: Print and confirming a hold can cause an infinite loop Test plan: 1) Place a hold for pickup at library A 2) Confirm the hold and print slip 3) Checkin the item again 4) Confirm the hold and print slip 5) The modal returns, do it again 6) Apply this patch 7) Reload the page 8) Repeat steps 1-3 9) No loop! Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 --- Comment #23 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Joonas Kylmälä from comment #17)
The patch "Bug 25969: Don't set itemnumber as reserve->itemnumber" here breaks printing hold slip in returns.pl page if you try to print it more than once. So if you return the hold first once, it prints the slip fine and goes to waiting state, then if you check in the item another time and try to print the slip the Internal server error comes.
This issue doesn't happen anymore with the latest master version. I'm not exactly sure which commit did the fix. So the patch "Bug 25969: (follow-up) If not coming from hold modal find item by barcode" is not at least required anymore to fix this, I don't know if it would be useful in other cases. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #111328|0 |1 is obsolete| | --- Comment #24 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Comment on attachment 111328 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111328 Bug 25969: (follow-up) If not coming from hold modal find item by barcode This has not been pushed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #111344|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25969 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28259 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org