Bug 2142 - maxItemsInSearchResults No longer used
Summary: maxItemsInSearchResults No longer used
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Ian Walls
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-19 12:25 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 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:


Attachments
patch (22.21 KB, patch)
2011-01-11 15:37 UTC, Nicole C. Engard
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 00:47:02 UTC


---- 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

Comment 1 Nicole C. Engard 2010-06-02 10:49:55 UTC
any word on this?
Comment 2 Mason James 2010-07-27 12:35:44 UTC
(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 :/
Comment 3 Nicole C. Engard 2011-01-11 15:37:32 UTC
Created attachment 2973 [details] [review]
patch
Comment 4 Chris Cormack 2011-01-11 20:00:50 UTC
Pushed, please test
Comment 5 MJ Ray (software.coop) 2011-02-04 09:13:29 UTC
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
Comment 6 Ian Walls 2011-02-08 03:32:52 UTC
Patch tested and confirmed.  Closing ticket.