Bug 4268

Summary: Incorrect check of OPACItemsResultsDisplay preference
Product: Koha Reporter: Magnus Enger <magnus>
Component: System AdministrationAssignee: Owen Leonard <oleonard>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: PATCH-Sent (DO NOT USE) CC: fridolin.somers, januszop, katrin.fischer, mtompset, nengard
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5409
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 1348    
Attachments: Proposed fix
restore OPACItemsResultsDisplay as a choice

Description Chris Cormack 2010-05-21 01:25:10 UTC


---- Reported by magnus@enger.priv.no 2010-02-25 14:45:52 ----

[14:52] magnus: i have a problem with  OPACItemsResultsDisplay - it doesn't do anything! The options are "Show/Don't show an item's branch, location and call number in OPAC search results." but when i check in mysql it says "options: statuses|itemdetails". The syspref toggels value between 1 and empty, but it should be setting it to statuses or itemdetails?
[14:56] magnus: i did "update systempreferences set value = 'itemdetails' where variable = 'OPACItemsResultsDisplay';" and now the call numbers are displayed
[15:00] gmcharlt: magnus: good catch - definition of OPACItemsResultsDisplay is wrong in searching.pref



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

This bug was previously known as _bug_ 4268 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4268

Actual time not defined. Setting to 0.0

Comment 1 Owen Leonard 2010-09-16 14:18:28 UTC
> ---- Reported by magnus@enger.priv.no 2010-02-25 14:45:52 ----

> The syspref toggels value between 1 and empty, but it
> should be setting it to statuses or itemdetails?

searching.pref says:

            - pref: OPACItemsResultsDisplay
              type: boolean
              choices:
                  yes: Show
                  no: "Don't show"
            - "an item's branch, location and call number in OPAC search results."

Toggling between 1 and empty works fine if you modify opac-search.pl line 545 from:

OPACItemsResultsDisplay => (C4::Context->preference("OPACItemsResultsDisplay") eq "itemdetails"?1:0),

to:

OPACItemsResultsDisplay => C4::Context->preference("OPACItemsResultsDisplay"),

That makes the preference work in my tests without making any changes to the pref files or to the database.
Comment 2 Owen Leonard 2010-09-16 14:40:21 UTC
Created attachment 2632 [details] [review]
Proposed fix

This patch changes how the preference is checked by opac-search.pl
rather than changing the way the data is saved in the systempreferences
table.
Comment 3 Fridolin Somers 2010-10-01 08:24:05 UTC
Don't forget to update database scripts also.
Comment 4 Fridolin Somers 2010-10-01 08:47:40 UTC Comment hidden (obsolete)
Comment 5 Owen Leonard 2010-12-30 13:24:47 UTC
*** Bug 5558 has been marked as a duplicate of this bug. ***
Comment 6 Nicole C. Engard 2011-05-13 20:01:26 UTC
I"m not sure I understand what the problem is, but I disagree with the second patch because it is not written as a sentence like other preferences and really makes no sense (and I know Koha).
Comment 7 Fridolin Somers 2011-05-17 14:21:51 UTC
(In reply to comment #6)
> I"m not sure I understand what the problem is, but I disagree with the second
> patch because it is not written as a sentence like other preferences and really
> makes no sense (and I know Koha).

I agree with you, I prefer to change syspref value into 1/0.

Then Owen's patch is good.

But we have to think about database content update no ?
Comment 8 Katrin Fischer 2011-05-22 19:31:55 UTC
Ok, looking at this it seems to me that Owen's patch will work for new databases but will not work for existing ones with old values in the systempreferences table. So I think Fridolyn is right and a database update is needed to go along with it. Marking Failed QA until a follow up is available - plz change status if you think otherwise.
Comment 9 Jared Camins-Esakov 2013-01-02 01:58:21 UTC
I am a little confused about this patch. The discussion seems to be about a different patch than the one currently on the bug. Is a patch still required?
Comment 10 Fridolin Somers 2013-01-02 15:35:05 UTC
for me this is a duplicate of Bug 5409
Comment 11 Mark Tompsett 2015-10-19 22:05:35 UTC
Two years later and no follow up. As far as I can tell with the current state of things, the obsoleted patch seems to have been the cause of things discussed in comments 1 through 8 and leading up to jcamin's confusion in comment #9, but that obsolete patch is not in master. And the proposed fix was addressed in Bug 5409 as noted in comment #10. Given this inactivity, I am marking this resolved duplicate.

*** This bug has been marked as a duplicate of bug 5409 ***