---- Reported by jwagner@ptfs.com 2009-09-24 13:18:53 ---- Created an attachment Search to hold button on checkout tab screenshot Sponsored by Middletown Township Public Library, Middletown, NJ, USA. This feature puts a "Search to Hold" button on the patron checkout tab. Clicking that button pops up an advanced search screen on top of the patron checkout tab. Search for an item, and a "Hold for patronname" button appears in the results list on each title. You can place a hold for the current patron by clicking that button on the results list, or by going into a title from the search list and using the same "Hold for" button. ---- Additional Comments From jwagner@ptfs.com 2009-09-24 13:19:43 ---- Created an attachment Search popup with Hold For button in results list screenshot ---- Additional Comments From jwagner@ptfs.com 2009-09-24 13:20:10 ---- Created an attachment Search popup with Hold For button in title display screenshot ---- Additional Comments From oleonard@myacpl.org 2009-09-24 13:45:54 ---- I suggest adding this to the patron toolbar rather than the checkout form. ---- Additional Comments From jwagner@ptfs.com 2010-05-12 13:28:15 ---- The fix for this bug (in ptfs-harley) can be pulled from the public git repository at http://github.com/Koha-PTFS, branch http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3659 --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:13 UTC --- This bug was previously known as _bug_ 3659 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3659 Imported an attachment (id=1490) Imported an attachment (id=1491) Imported an attachment (id=1492) Unknown operating system Windows 2000. Setting to default OS "All". Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was jwagner@ptfs.com. The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, gmcharlt@gmail.com. Previous assignee was kohaprogrammers@ptfs.com. Bug reassigned, setting status to "NEW". Previous status was "ASSIGNED". The original submitter of attachment 1490 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 1491 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. The original submitter of attachment 1492 [details] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
Created attachment 2974 [details] Search to hold alternative process, step 1 I've tested the "search to hold" feature developed by PTFS and found it a little cumbersome: Putting the "action" into a modal window creates complications because the window contains the whole interface, including possible actions unrelated to the goal of placing a hold. For instance, from within that window I could abandon my search and start checking out to another patron. I could launch another "search to hold" window within the first search to hold window! I propose that instead of trying to juggle the borrowernumber as a GET variable passed among windows we set it as a session-limited cookie. In this screenshot of my proposed alternative, clicking the "Search to hold" button sets a cookie with the patron's borrowernumber and redirects you to the search screen.
Created attachment 2975 [details] Search to hold alternative process, step 2
Created attachment 2976 [details] Search to hold alternative process, step 3 On the search results page Koha checks for the cookie containing a borrowernumber. If it finds one, it displays a link to place a hold for that patron.
Created attachment 2977 [details] Search to hold alternative process, step 4 If you click through to the detail page from the search results you'll find that the standard "Place hold" button is now a "split button." The default action of the button is the standard place hold behavior. If you click the optional menu you have the choice placing a hold for the patron Koha is currently tracking.
One question I haven't addressed yet: Should you be able to tell Koha to "forget" it was tracking that patron? If so, what is the best way/best place to handle that?
I like your implementation of this a lot! Regarding your question: Maybe set the cookie on each patron scan, expire it after 5-10 minutes (or however long you think)?
> Should you be able to tell Koha to > "forget" it was tracking that patron? After some discussion with Liz, I've added a couple of things: 1. The cookie will expire after a certain number of minutes. What's good? 10? 5? 2. The cookie will be deleted when you load a new patron on circulation.pl
Liz points out another feature which this should accommodate: The ability to place multiple holds from the search results screen for the remembered patron.
Created attachment 2995 [details] [review] Proposed fix
Pushed please test
Got my branches mixed up and submitted the wrong patch! I've asked chris to revert it. I'll submit the correct one.
Created attachment 3043 [details] [review] Revised fix Revision fixes some markup and corrects an error that would lead to the hold being initiated for the remembered patron when this was not intended.
This bug is mentioned in: Fix for Bug 3659, Add place hold option from patron checkout tab http://lists.koha-community.org/pipermail/koha-patches/2011-January/013605.html [SIGNED-OFF]Fix for Bug 3659, Add place hold option from patron checkout tab http://lists.koha-community.org/pipermail/koha-patches/2011-January/013613.html Fix for Bug 3659, Add place hold option from patron checkout tab http://lists.koha-community.org/pipermail/koha-patches/2011-January/013726.html
I confirm this is completed and works in master. Thanks Owen!