---- Reported by nengard@gmail.com 2008-05-19 12:25:38 ---- maxItemsInSearchResults should not be an option anymore, as it's no longer used. JMF - This syspref is deprecated -- it used to specify what the max number of items to display for every bib entry in the results. It was needed because some bibs have several hundred items attached and it wasn't economical to display them all ---- Additional Comments From jmf@liblime.com 2008-06-20 15:43:14 ---- fixed in new installations, in old ones, delete manually ---- Additional Comments From oleonard@myacpl.org 2009-07-23 15:32:33 ---- This preference is still referenced in Search.pm. ---- Additional Comments From tajoli@cilea.it 2009-10-15 12:17:25 ---- Now is present only in installer/data/mysql/fr-FR/1-Obligatoire/unimarc_standard_systemprefs.sql installer/data/mysql/updatedatabase.pl in HEAD (3.2) and in 3.0.x Not used at all. To delete at all and after close the bug ---- Additional Comments From 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. ---- Additional Comments From jwagner@ptfs.com 2009-12-03 13:19:08 ---- As a followup, the problem with the XSLT results list display was an unrelated red herring -- see David Birmingham's patch of December 2, 2009 about ampersands in the library description. But the problem with having maxItemsinSearchResults in Search.pm remains. ---- Additional Comments From nengard@gmail.com 2009-12-28 00:35:02 ---- sorry - just saw that i had closed it and it was reopened - reopening again :) ---- Additional Comments From nengard@gmail.com 2010-02-07 15:01:29 ---- Any luck on resolving this? --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:47 UTC --- This bug was previously known as _bug_ 2142 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2142 This bug blocked bug(s) 4430. Actual time not defined. Setting to 0.0 CC member jwagner@ptfs.com does not have an account here
any word on this?
(In reply to comment #1) > any word on this? bugger, i just hit this one too! the best thing to do, until this gets properly patched is to add a new 'maxItemsinSearchResults' syspref, and set it to 10 or 20... (depending on the your system-performance and max-number-of-items per bib) this missing syspref really needs to be added back into stable/head until this is is properly patched, else you always get an availiability-count for *one* branch only :/
Created attachment 2973 [details] [review] patch
Pushed, please test
This bug is mentioned in: Bug 2142: reinstate maxItemInSearchResults systempreference http://lists.koha-community.org/pipermail/koha-patches/2011-January/013573.html Bug 2142: reinstate maxItemInSearchResults systempreference http://lists.koha-community.org/pipermail/koha-patches/2011-January/013577.html Bug 2142: reinstate maxItemInSearchResults systempreference http://lists.koha-community.org/pipermail/koha-patches/2011-January/013578.html Bug 2142: reinstate maxItemInSearchResults systempreference http://lists.koha-community.org/pipermail/koha-patches/2011-January/013579.html
Patch tested and confirmed. Closing ticket.