[Bug 2142] maxItemsInSearchResults No longer used
http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2142 Jane Wagner <jwagner@ptfs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwagner@ptfs.com Severity|normal |major Priority|P3 |P2 --- Comment #4 from Jane Wagner <jwagner@ptfs.com> 2009-12-01 20:28:41 --- I'm reopening and increasing priority on this one. In a system newly installed from HEAD just a couple of weeks ago (3.01.00.061), the maxItemsinSearchResults is still present (in two sections) in Search.pm, and has a negative effect. For a multilibrary system, when the Search.pm code has a default of 1, only one library's holdings would show in the OPAC or staff results list my $maxitems = ( C4::Context->preference('maxItemsinSearchResults') ) ? C4::Context->preference('maxItemsinSearchResults') - 1 : 1; my ( $availableitemscount, $onloanitemscount, $otheritemscount ); $maxitems = ( C4::Context->preference('maxItemsinSearchResults') ) ? C4::Context->preference('maxItemsinSearchResults') - 1 : 1; When we changed Search.pm from 1 to 5 (for example), all library holdings showed up in both results lists. However, for the OPAC, they'll only show up if XSLTResultsDisplay is turned off -- if it's on, the OPAC results list says No copies available for everything. So either the syspref needs to be put back or Search.pm needs to be fixed; I'm not sure how to fix it and why it's causing a problem with XSLT results. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
bugzilla-daemon@kohaorg.ec2.liblime.com