http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Change sponsored?|--- |Sponsored CC| |kyle.m.hall@gmail.com -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39998|0 |1 is obsolete| | --- Comment #2 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 41236 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=41236&action=edit [SIGNED-OFF] Bug 14364 - Allow automatically canceled expired waiting holds to fill the next hold Right now, if a library automatically cancels expired waiting holds, a librarian must still re-checkin an item to trap the next available hold for that item. It would be better if the next hold was automatically trapped and the librarians receive an email notification so they can make any changes to the item if need be ( hold area, hold slip in item, etc ). Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with one item 4) Place two holds on that record 5) Check in the item and set it to waiting for the first patron 6) Set ReservesMaxPickUpDelay to 1 7) Enable ExpireReservesMaxPickUpDelay 8) Enable ExpireReservesAutoFill 9) Set an email address in ExpireReservesAutoFillEmail 10) Modify the holds waitingdate to be in the past 11) Run misc/cronjobs/holds/cancel_expired_holds.pl 12) Note the hold is now waiting for the next patron 12) Note a waiting hold notification email was sent to that patron 13) Note a hold changed notification email was sent to the library Signed-off-by: Gene Miller <genem@takomaparkmd.gov> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Zeno Tajoli <z.tajoli@cineca.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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? 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. 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. Christopher -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #6 from Kyle M Hall <kyle.m.hall@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.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nick Clemens <nick@quecheelibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@quecheelibrary.org -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard@gmail.com Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply --- Comment #9 from Nick Clemens <nick@bywatersolutions.com> --- simple notice conflicts, less simple Reserves.pm conflict -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #41236|0 |1 is obsolete| | --- Comment #10 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 45149 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45149&action=edit Bug 14364 - Allow automatically canceled expired waiting holds to fill the next hold Right now, if a library automatically cancels expired waiting holds, a librarian must still re-checkin an item to trap the next available hold for that item. It would be better if the next hold was automatically trapped and the librarians receive an email notification so they can make any changes to the item if need be ( hold area, hold slip in item, etc ). Test Plan: 1) Apply this patch 2) Run updatedatabase.pl 3) Create a record with one item 4) Place two holds on that record 5) Check in the item and set it to waiting for the first patron 6) Set ReservesMaxPickUpDelay to 1 7) Enable ExpireReservesMaxPickUpDelay 8) Enable ExpireReservesAutoFill 9) Set an email address in ExpireReservesAutoFillEmail 10) Modify the holds waitingdate to be in the past 11) Run misc/cronjobs/holds/cancel_expired_holds.pl 12) Note the hold is now waiting for the next patron 12) Note a waiting hold notification email was sent to that patron 13) Note a hold changed notification email was sent to the library Signed-off-by: Gene Miller <genem@takomaparkmd.gov> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to bondiurbano from comment #11)

This solution fixes bug#10827 "List of holds does not update correctly". If you agree I will set it as RESOLVED.

Maybe better to mark it as a duplicate. I wouldn't set it resolved until a solution has made it into master. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #14 from bondiurbano <costalc@gmail.com> --- *** Bug 10827 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 --- Comment #16 from Nick Clemens <nick@bywatersolutions.com> --- The holds transfer as expected, and the patron gets the email but I am not getting the admin email. I also got the error below when running misc/cronjobs/holds/cancel_expired_holds.pl: DBD::mysql::st execute failed: Duplicate entry '6' for key 'PRIMARY' [for Statement " INSERT INTO old_reserves SELECT * FROM reserves WHERE reserve_id = ? " with ParamValues: 0='6'] at C4/Reserves.pm line 1080. Can't locate object method "new" via package "C4::Dates" (perhaps you forgot to load "C4::Dates"?) at C4/Reserves.pm line 2073. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicole@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.