|
Description
Nick Clemens (kidclamp)
2016-12-20 18:53:20 UTC
I can confirm. In my case it was a transfer slip, but the item didn't get changed to the transport status and the hold remains pending. Is this a regression or a behaviour change request? I think the button was introduced not so long ago - not sure if it ever worked differently, but it should work differently. Does that make sense? Having a book with the hold slip in it... that is not actually waiting is bound to cause you a lot of headache. I think if we can't fix this pre-release, we should consider removing the button altogether - at the moment I would hide it if I had a choice as a library, as the feature behind it is broken. > To my understanding, this is what happened : > > Situation 1 (regular) > > - Patron A put a hold on Book A > - Book A is returned. Hold is confirmed. > - Patron B checkout Book A > - Koha says "This book is on hold for Patron A, what do you want to do?" > - The button "Don't checkout and print" allows you to cancel the process and > print a slip. > - It keeps the book on hold for Patron A. It's actually already on hold so > there should be no reason to update it. If the item is already on hold for the patron it will allow to reprint the hold slip. Sounds good. > BUT, here comes situation 2 (exception) > > - Patron A put a hold on Book A > - Book A is returned. Hold is NOT confirmed (Library wants to confirm the > hold later to control when the confirmation email is sent, or library had > forgotten, etc.) > - Patron B checkout Book A > - Koha says "This book is on hold for Patron A, what do you want to do?" > - The button "Don't checkout and print" allows you to cancel the process and > print a slip. > - The hold is not confirmed and this button doesn’t update it. I think that's wrong - you should not have a hold slip if no email is generated and the hold is not set to waiting. The slip should only happen if the hold is waiting or set to waiting - otherwise you end up with 'available' items on the hold shelf. I wonder if the message could be better as on hold sounds like it's already waiting, but it's not. We should have different messages for already waiting and having a hold on it that's not yet confirmed. I think what Nick describes is a 3rd option: hold for A, don't confirm hold, try to checkout to A. In this case, the item was not waiting and should be set to waiting. (In reply to Katrin Fischer from comment #6) > > To my understanding, this is what happened : > > > > Situation 1 (regular) > > > > - Patron A put a hold on Book A > > - Book A is returned. Hold is confirmed. > > - Patron B checkout Book A > > - Koha says "This book is on hold for Patron A, what do you want to do?" > > - The button "Don't checkout and print" allows you to cancel the process and > > print a slip. > > - It keeps the book on hold for Patron A. It's actually already on hold so > > there should be no reason to update it. > > If the item is already on hold for the patron it will allow to reprint the > hold slip. Sounds good. > > > > BUT, here comes situation 2 (exception) > > > > - Patron A put a hold on Book A > > - Book A is returned. Hold is NOT confirmed (Library wants to confirm the > > hold later to control when the confirmation email is sent, or library had > > forgotten, etc.) > > - Patron B checkout Book A > > - Koha says "This book is on hold for Patron A, what do you want to do?" > > - The button "Don't checkout and print" allows you to cancel the process and > > print a slip. > > - The hold is not confirmed and this button doesn’t update it. > > I think that's wrong - you should not have a hold slip if no email is > generated and the hold is not set to waiting. The slip should only happen if > the hold is waiting or set to waiting - otherwise you end up with > 'available' items on the hold shelf. > > I wonder if the message could be better as on hold sounds like it's already > waiting, but it's not. We should have different messages for already waiting > and having a hold on it that's not yet confirmed. > > I think what Nick describes is a 3rd option: hold for A, don't confirm hold, > try to checkout to A. In this case, the item was not waiting and should be > set to waiting. Yes, as I follow things this is correct - I was thinking of the situation where: A places a hold from home B picks up the book off the shelf before a hold list is checked Try to checkout to B, print slip, hold never confirmed I think you are getting at language something like: this item has a hold for Patron A versus this item is on hold for Patron A Created attachment 158281 [details] [review] Bug 17798: Confirm hold when printing slip from another patron's account This patch adds a few pieces of information to the print slip button and makes the code confirm the hold As we are printing before the confirm, we also add the ability to pass in the itemnumber to 'ReserveSlip' This is slightly hacky, however, I don't see another way to allow printing without an additional page reload. To test: 1 - Place a title level hold for patron A, for delivery to library B 2 - Attempt to checkout an item from the record above to Patron B from library A 3 - You receive an alert about the hold 4 - Click "Don't check out, confirm hold, and print slip" 5 - Confirm the slip looks correct and has item info 6 - Confirm that item is in transit to fill hold 7 - Revert transit status 8 - Attempt to checkout the item to Patron B from Library B 9 - Click "Don't check out, confirm hold, and print slip" 10 - Confirm slip is correct 11 - Confirm item is marked waiting Created attachment 158282 [details] [review] Bug 17798: Add fieldset for 'Yes, check out (Y)' With the increased text, the buttons don't arrange neatly. Adding a fieldset around the options for 'Yes' mitigates this somewhat - it could do with a bit more styling, however, it also fixes bug 23953 To test: Confirm the 'Yes' options are more clear that they only affect the yes button Confirm the other buttons arrange nicely Created attachment 158330 [details] [review] Bug 17798: Confirm hold when printing slip from another patron's account This patch adds a few pieces of information to the print slip button and makes the code confirm the hold As we are printing before the confirm, we also add the ability to pass in the itemnumber to 'ReserveSlip' This is slightly hacky, however, I don't see another way to allow printing without an additional page reload. To test: 1 - Place a title level hold for patron A, for delivery to library B 2 - Attempt to checkout an item from the record above to Patron B from library A 3 - You receive an alert about the hold 4 - Click "Don't check out, confirm hold, and print slip" 5 - Confirm the slip looks correct and has item info 6 - Confirm that item is in transit to fill hold 7 - Revert transit status 8 - Attempt to checkout the item to Patron B from Library B 9 - Click "Don't check out, confirm hold, and print slip" 10 - Confirm slip is correct 11 - Confirm item is marked waiting Signed-off-by: Owen Leonard <oleonard@myacpl.org> Created attachment 158331 [details] [review] Bug 17798: Add fieldset for 'Yes, check out (Y)' With the increased text, the buttons don't arrange neatly. Adding a fieldset around the options for 'Yes' mitigates this somewhat - it could do with a bit more styling, however, it also fixes bug 23953 To test: Confirm the 'Yes' options are more clear that they only affect the yes button Confirm the other buttons arrange nicely Signed-off-by: Owen Leonard <oleonard@myacpl.org> Created attachment 158332 [details] [review] Bug 17798: (follow-up) Adjust color of fieldset nested in .dialog.alert Signed-off-by: Owen Leonard <oleonard@myacpl.org> Created attachment 158387 [details] [review] Bug 17798: Confirm hold when printing slip from another patron's account This patch adds a few pieces of information to the print slip button and makes the code confirm the hold As we are printing before the confirm, we also add the ability to pass in the itemnumber to 'ReserveSlip' This is slightly hacky, however, I don't see another way to allow printing without an additional page reload. To test: 1 - Place a title level hold for patron A, for delivery to library B 2 - Attempt to checkout an item from the record above to Patron B from library A 3 - You receive an alert about the hold 4 - Click "Don't check out, confirm hold, and print slip" 5 - Confirm the slip looks correct and has item info 6 - Confirm that item is in transit to fill hold 7 - Revert transit status 8 - Attempt to checkout the item to Patron B from Library B 9 - Click "Don't check out, confirm hold, and print slip" 10 - Confirm slip is correct 11 - Confirm item is marked waiting Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 158388 [details] [review] Bug 17798: Add fieldset for 'Yes, check out (Y)' With the increased text, the buttons don't arrange neatly. Adding a fieldset around the options for 'Yes' mitigates this somewhat - it could do with a bit more styling, however, it also fixes bug 23953 To test: Confirm the 'Yes' options are more clear that they only affect the yes button Confirm the other buttons arrange nicely Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 158389 [details] [review] Bug 17798: (follow-up) Adjust color of fieldset nested in .dialog.alert Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Pushed to master for 23.11. Nice work everyone, thanks! Pushed to 23.05.x for 23.05.06 Nice work everyone! Pushed to 22.11.x for next release |