To recreate: * Place an item level hold on the item with no barcode * Place an item level hold on any other item * From the Holds tab, change the dropdown of the first one from "no barcode" to "next available" * Update holds * Both item level holds are now next available holds.
Created attachment 169872 [details] [review] Bug 37413: Prevent altering multiple item-level holds when setting one with no barcode to next available To test: 1) Place an item level hold on the item with no barcode 2) Place an item level hold on any other item 3) From the Holds tab, change the dropdown of the first one from "no barcode" to "next available" 4) Update holds 5) Both item level holds are now next available holds. 6) Cancel these holds and repeats steps 1-4 again 7) This time, only the hold we switched to "next available" is changed
Created attachment 169877 [details] [review] Bug 37413: Prevent altering multiple item-level holds when setting one with no barcode to next available To test: 1) Place an item level hold on the item with no barcode 2) Place an item level hold on any other item 3) From the Holds tab, change the dropdown of the first one from "no barcode" to "next available" 4) Update holds 5) Both item level holds are now next available holds. 6) Cancel these holds and repeats steps 1-4 again 7) This time, only the hold we switched to "next available" is changed Signed-off-by: David Nind <david@davidnind.com>
Created attachment 169942 [details] [review] Bug 37413: [Alternative] Ensure itemnumber is sent Fix condition to ensure the itemnumber is sent
Hi guys. To me it seems the problem is caused by the fact that the itemnumber is not sent to the server if the item of the hold does not contain a barcode. The provided patch is working around the problem, not fixing it. I don't know if this behavior is intended (not send an itemnumber if barcode missing) or copy paste oversight, but this is how it was submitted originally by Lari Taskula: https://github.com/Koha-Community/Koha/commit/c20f456 I've added Lari to this bug to provide a chance to intervene if required. Sorry if I'm completely off base here. Happy to discuss further.
(In reply to Pedro Amorim from comment #4) > I don't know if this behavior is intended I can't recall nor think of a reason for making it intended. As you said it was probably a copypaste oversight. Without testing (out of office at the moment), your new patch does make sense. Thanks!
Created attachment 169947 [details] [review] Bug 37413: [Alternative] Ensure itemnumber is sent Fix condition to ensure the itemnumber is sent Signed-off-by: Sam Lau <samalau@gmail.com>
Created attachment 170637 [details] [review] Bug 37413: [Alternative] Ensure itemnumber is sent Fix condition to ensure the itemnumber is sent Signed-off-by: Sam Lau <samalau@gmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Pushed for 24.11! Well done everyone, thank you!
Backported to 24.05.x for upcoming 24.05.04
Pushed to 23.11.x for 23.11.10
Not backporting to 23.05.x unless requested