Bug 3785 - New Install, no maxreserves setting, OPAC holds fail
Summary: New Install, no maxreserves setting, OPAC holds fail
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) major
Assignee: Chris Cormack
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-16 02:17 UTC by Jane Wagner
Modified: 2012-10-25 23:10 UTC (History)
5 users (show)

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


Attachments
Patch (1.46 KB, patch)
2009-12-15 23:21 UTC, Chris Cormack
Details | Diff | Splinter Review

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


---- Reported by jwagner@ptfs.com 2009-11-16 14:17:40 ----

On a new git install, if the site has not set any value in the maxreserves syspref, trying to place a hold through the OPAC results in a blank screen.  There is no visible error message, but the error log says:

opac-reserve.pl: Argument "" isn't numeric in numeric ge (>=) at /home/servername/kohaclone/opac/opac-reserve.pl line 265.

When I look at line 265 in opac-reserve.pl, here's the code block:

if ( scalar(@reserves) >= $MAXIMUM_NUMBER_OF_RESERVES ) {
    $template->param( message => 1 );
    $noreserves = 1;
    $template->param( too_many_reserves => scalar(@reserves));
}

Setting a numeric value in the syspref made holds work OK, but the code needs to be fixed so that it accounts for a null or empty entry.  How best to do that?

I'm not sure what section of code to check, to see if staff-side holds has the same problem.



---- Additional Comments From nengard@gmail.com 2009-12-07 15:45:22 ----

upping priority - the fact that you can't place holds and that this is missing are big deals.  Also changing version - this is the issue in the current HEAD version.



---- Additional Comments From chris@bigballofwax.co.nz 2009-12-15 23:21:24 ----

Created an attachment
Patch





---- Additional Comments From cnighswonger@foundations.edu 2010-02-01 16:48:05 ----

It seems that this syspref should be done away with and opac-reserve.pl be made to obey the issuerules. In turn, there should be a 'standard' default rule to fall back on.



---- Additional Comments From gmcharlt@gmail.com 2010-04-30 12:22:44 ----

Pushed the  C4/ILSDI/Utility.pm portion of Chris Cormack's patch to HEAD.  Commit 6e376d04 by Chris Nighswonger, pushed earlier, handled the opac-reserve.pl part.

Recommend leaving open because of Chris Nighswonger's comment about the need to replace the system preference with a check of the issuingrules, but downgrading to major.




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

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

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 submitter of attachment 1571 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Chris Cormack 2010-12-13 03:54:41 UTC
This still needs some work