[Koha-bugs] [Bug 17798] Checking out an item on hold for another patron prints a slip but does not update hold

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17798

--- Comment #7 from Nick Clemens <nick at bywatersolutions.com> ---
(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

-- 
You are receiving this mail because:
You are watching all bug changes.