[Koha-bugs] [Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold

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

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364

--- Comment #6 from Kyle M Hall <kyle.m.hall at gmail.com> ---
(In reply to Christopher Brannon from comment #4)
> I'm not sure how many libraries would like this workflow.  Having the system
> to make changes to the item and notify a patron before the staff have a
> chance to handle it is not a common practice.  I haven't had a chance to
> test it yet, but wouldn't the staff grabbing the item and checking it in to
> generate a slip cause it to send out another notification?

Since the hold is already waiting at that point, another notification would not
be sent.

> Having a hold notify a patron before the item is prepped can introduce some
> issues.  For example, what if the person comes in before the staff have read
> the e-mail and processed the book.  How do other staff find the item?  We
> often have patrons come to the desk literally minutes after the notification
> goes out, and the patron happens to be in the library.  This produces a kink
> in the workflow and has the potential to frustrate both patron and staff.
> 
> What would be preferred is the following (at least at our library):
> 
> 1) Waiting hold expires or is cancelled.
> 2) Staff alerted and item status is changed so as not to show that it is
> available, but the hold is over.
> 3) Staff grab books and check them in.
> 4) Koha sees that they have expired or cancelled holds and asks if you would
> like to move the item on to the next hold (if one exists), or renew the hold.
> 5) A new slip is generated in either case, and the item is moved on or back
> on the hold shelf.
> 
> This is just my opinion, but I think my suggested workflow is more
> acceptable.

That is essentially Koha's existing holds workflow. The only difference would
be to make item's as unavailable if the item would fill the next hold. It's not
insurmountable, but would definitely be a separate feater that could live along
side of this one ( in an either/or fashion ).

> I'm not changing the status on the enhancement to in discussion, since this
> is an option and not a fundamental change, but I'm not sure how many folks
> will go for this.

Input is always appreciated. Indeed this is an entirely optional workflow that
I'm sure will work great for some libraries ( like the one that requested the
feature ) and not at all for others ( like you and Heather ).

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