Bug 4359 - noItemTypeImages not active in OPAC
Summary: noItemTypeImages not active in OPAC
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Owen Leonard
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 5704
  Show dependency treegraph
 
Reported: 2010-03-31 06:19 UTC by Jane Wagner
Modified: 2012-10-25 23:09 UTC (History)
3 users (show)

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


Attachments
Proposed fix (7.56 KB, patch)
2010-07-06 14:50 UTC, Owen Leonard
Details | Diff | Splinter Review
ugly detail display (114.69 KB, image/png)
2011-02-07 16:09 UTC, Nicole C. Engard
Details

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


---- Reported by jwagner@ptfs.com 2010-03-31 18:19:18 ----

The admin syspref noItemTypeImages appears to have no effect at all in the OPAC.  If an item type has an image assigned, it will display regardless of whether the syspref is on or off.  The icons show up in the advanced search page and on title display pages (and independent of XSLT being on or off).  Is this by design?  Or should the OPAC be told to obey the syspref?  So far as I can tell, the syspref does work properly for staff mode.

For advanced search, the problem seems to be in opac-search.pl, in this segment:

        my %row =(  number=>$cnt++,
                                ccl => $itype_or_itemtype,
                code => $thisitemtype,
                selected => $selected,
                description => $itemtypes->{$thisitemtype}->{'description'},
                count5 => $cnt % 4,
                imageurl=> getitemtypeimagelocation( 'opac', $itemtypes->{$thisitemtype}->{'imageurl'} ),
            );


The imageurl line should check for the syspref.  Haven't looked at the details display code yet.

I'm thinking there should be a separate OPACnoItemTypeImages so that staff and OPAC can be set differently.  Both the advanced search page and the title display page should obey it.



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

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

Unknown operating system Windows 2000. Setting to default OS "All".
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.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Owen Leonard 2010-07-06 14:50:14 UTC
Created attachment 2312 [details] [review]
Proposed fix

- Auth.pm put the noItemTypeImages preference under "intranet only."
  Moved it to "OPAC or intranet."
- Added check for the preference on the OPAC advanced search page.
- Improved logic for displaying images on the reading history page.
Comment 2 Owen Leonard 2010-07-06 14:55:41 UTC
There is now Bug 4944 for the creation of separate OPAC and staff client preferences.
Comment 3 Chris Cormack 2010-11-13 07:27:15 UTC
Patch pushed
Comment 4 Chris Nighswonger 2010-11-18 03:15:07 UTC
This bug has a patch presently committed to HEAD and 3.2.x.

Please take the appropriate action to update the status of this bug.

Remember, bugs which have been resolved should be tested and marked closed, preferably by the original reporter.
Comment 5 Chris Nighswonger 2010-11-30 13:49:20 UTC
This bug has a fix which was committed to the 3.2.x branch and released in 3.2.1.

Please take time to update the status of this bug and mark it RESOLVED FIXED so that it may be closed.
Comment 6 Jane Wagner 2010-11-30 15:40:54 UTC
Seems to be fixed in current head.  Thanks.
Comment 7 Chris Nighswonger 2010-11-30 15:54:44 UTC
A fix for this bug has been committed to the current development HEAD as well as released in 3.2.1.
Comment 8 Nicole C. Engard 2011-02-07 16:09:24 UTC
Created attachment 3080 [details]
ugly detail display

On the detail page this patch screws with the layout
Comment 9 Owen Leonard 2011-02-07 16:18:55 UTC
Additional patches were pushed for this:

http://lists.koha-community.org/pipermail/koha-patches/2010-November/012954.html
http://lists.koha-community.org/pipermail/koha-patches/2010-November/012957.html

The latter creates a problem, I believe, in that it causes item type images to
display on the search results page even if item-level itemtypes are turned on.
If item-level itemtypes are turned on a catalog might have:

1. Biblios with no biblio-level item type.
2. Biblios with multiple item-level item types.

In both cases there isn't a way for Koha do properly display a single item type
icon. For this reason I think display of item type icons on the search results
page should be contingent on item-level_itypes being OFF.
Comment 10 Owen Leonard 2011-02-07 17:03:32 UTC
> The latter creates a problem, I believe, in that it causes item type images to
> display on the search results page even if item-level itemtypes are turned on.

Correction: It's not this commit that caused this item type image display problem, it was this one, for Bug 5462:

http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=c02e4d02d5c4ebcb01d60c4515cde3b13765fb07
Comment 11 Katrin Fischer 2011-08-14 09:57:16 UTC
Retested in current master.

With 'NoItemTypeImages' set to 'Don't show':
- images not shown on advanced search
- images not shown in detail pages

With 'NoItemTypeImages' set to 'Show'
- images show on advanced search
- images show on detail pages

There is still only one pref for staff and OPAC. I think this should go on a separate enh bug, if we want to do this.

I detected no layout problems.

Closing bug, please reopen if I missed something.