Bug 3093 - Enhance placing of holds in staff interface
Summary: Enhance placing of holds in staff interface
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: PC All
: PATCH-Sent (DO NOT USE) enhancement
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-06 06:37 UTC by Chris Cormack
Modified: 2012-10-25 22:53 UTC (History)
4 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
patch file (10.39 KB, application/octet-stream)
2009-11-11 15:53 UTC, Chris Cormack
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:06:19 UTC


---- Reported by sedwards@alloycomputing.com 2009-04-06 18:37:49 ----

Pre-existing functionality includes placing holds on a single title from the

1) search results list by clicking on the Holds link.
2) full bib record by clicking on the Holds tab.

New features would include:

1) selecting multiple titles at once.
2) placing holds on multiple titles at once.

This will be accomplished in two ways:

1) From search results by adding check boxes to titles on the list.

* Titles not eligible for request will not display a check box.
    
* There will be a Select All option that selects all titles listed on that page, and a a Clear All button to de-select all titles
  
* Titles can be selected by clicking the Select All option or by clicking individual check boxes.
  
* Once titles have been selected on the search results page, the user may click a Place Hold button. After entering the patron barcode and selecting a pickup location, title-level requests are placed on all selected titles.

2) From Lists by adding Hold capability.

* This method requires that method 1 be in place.

* Once titles have been selected on the search results page, the user will click an Add to List button. After selecting a list or creating a new one, all selected titles are added to the list.
  
* Under More > Lists > Your Lists, check boxes already display, but add option to:
  
  . Place Hold



---- Additional Comments From sedwards@alloycomputing.com 2009-04-07 12:29:06 ----

Submitted patch.



---- Additional Comments From sedwards@alloycomputing.com 2009-04-22 17:39:51 ----

Added checkboxes to all search result items.  Only show "Place Hold" button if the user permissions allow placing reserves for others.



---- Additional Comments From sedwards@alloycomputing.com 2009-04-23 16:47:23 ----

Fixed display of item type.

When multiple holds are being requested, suppress the display of the vertical details menu and the item-level "Place Hold" button.



---- Additional Comments From gmcharlt@gmail.com 2009-04-24 11:49:23 ----

I've pushed the patch.  I'm seeing a large number of uninitialized value warnings in the Apache log - I would appreciate it if you would follow up with a patch to clean that up.

[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string comparison (cmp) at /home/gmc/koha/dev/reserve/request.pl line 436., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string comparison (cmp) at /home/gmc/koha/dev/reserve/request.pl line 436., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string eq at /home/gmc/koha/dev/reserve/request.pl line 457., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string eq at /home/gmc/koha/dev/reserve/request.pl line 491., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string eq at /home/gmc/koha/dev/reserve/request.pl line 457., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in string eq at /home/gmc/koha/dev/reserve/request.pl line 491., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34
[Fri Apr 24 06:42:53 2009] [error] [client 98.70.132.238] [Fri Apr 24 06:42:53 2009] request.pl: Use of uninitialized value in hash element at /home/gmc/koha/dev/reserve/request.pl line 516., referer: http://staff-gmc.dev.kohalibrary.com/cgi-bin/koha/reserve/request.pl?biblionumber=34



---- Additional Comments From sedwards@alloycomputing.com 2009-04-28 12:20:46 ----

I will try to take care of the log warnings this week.



---- Additional Comments From gmcharlt@gmail.com 2009-05-27 15:56:48 ----

(In reply to comment #5)
> I will try to take care of the log warnings this week.
> 

Where are you with this?



---- Additional Comments From sedwards@alloycomputing.com 2009-05-27 20:56:57 ----


Sorry, got sidetracked while testing.  You should see the patch tomorrow morning.


(In reply to comment #6)
> (In reply to comment #5)
> > I will try to take care of the log warnings this week.
> > 
> 
> Where are you with this?
> 




---- Additional Comments From sedwards@alloycomputing.com 2009-05-30 09:15:19 ----

Sorry, this is taking longer than expected.  I need to put this on hold for the coming week, but I will finish it up the next.



---- Additional Comments From jwagner@ptfs.com 2009-10-27 00:54:38 ----

Question -- why are item-level holds suppressed when using the multi-hold Place Hold button?  I can see that they are, and your comments indicate this is deliberate, but what's the reason?  I have a site that would really like to use the multiple Place Hold button, but needs to have holds allowed at the item level.

Before I go trying to change their code, I want to understand the history.  Thanks.




---- Additional Comments From jwagner@ptfs.com 2009-11-11 15:53:56 ----

Created an attachment
patch file

This feature is causing problems for a couple of my sites, so I wrote a syspref to turn it off if needed.



---- Additional Comments From gmcharlt@gmail.com 2010-05-11 11:51:14 ----

Pushed to HEAD.



---- Additional Comments From nengard@gmail.com 2010-05-11 16:39:06 ----

I have tested and this works as described, but patrons can still place holds on multiple items via lists and the cart.  Are you trying to disable multiple holds completely? Or just on the search page?



---- Additional Comments From nengard@gmail.com 2010-05-11 16:41:08 ----

Also this is only working in the OPAC - but the description doesn't say so.  Should it work only in the OPAC? If so we need to update the pref description.



---- Additional Comments From nengard@gmail.com 2010-05-11 16:46:15 ----

regarding my comment about the staff client - ignore me - the button is removed from the staff and the opac.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:06 UTC  ---

This bug was previously known as _bug_ 3093 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3093
Imported an attachment (id=1088)

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 sedwards@alloycomputing.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 sedwards@alloycomputing.com.
CC member arm@hanover.ca does not have an account here
CC member dhall@ebpl.org does not have an account here
CC member dianajweaver@gmail.com does not have an account here
CC member jwagner@ptfs.com does not have an account here
The original submitter of attachment 1088 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.