From c199f1354676e739c6f67b7806e96f7607f7a002 Mon Sep 17 00:00:00 2001 From: David Cook Date: Fri, 14 Jun 2013 13:03:19 +1000 Subject: [PATCH] Bug 10466 - Lists: Use "size" as names/hash keys leads to an unexpected results when using Template::Toolkit (name of a virtual method there) Content-Type: text/plain; charset=utf-8 This patch checks to see if "size" is undefined. If it is, we add a blank (i.e. "") value to it in place of undef. If we do not do this, calling "itemloo.size" will return the size of the "itemloo" hash, rather than the value for the "size" key. This is because "size" is a virtual method in Template Toolkit. It's uncertain why the value is retrieved for the "size" key when there is a defined value and why TT doesn't use the method instead, and that it uses "size" as a method only if there is either no "size" key or if the value tied to the "size" key is null/undef. This might be a feature or it might be a bug in TT... In the mean-time, we will check to see if it's undefined. If it is, we'll give it a value. This bug has been identified in the opac-search.pl, search.pl and addbooks.pl pages before. To address it, we're currently checking if there is a "size" key, and if not...we're adding one with a blank value. This patch takes up that same idea, although I think it might be better to rename the variable before passing it to TT in case the behaviour of TT changes in the future in regards to how it handles virtual methods. N.B. Obviously, this only affects users not using XSLTs. -- Test Plan: Before applying the patch: 0) Make sure you have opac search result XSLT turned off 1) Find bib records that do not have a 300$c (Dimensions) value. 2) Find bib records that do have a 300$c (Dimensions) value. (N.B. These values should be stored in the `size` column of biblioitems). 3) Add items from both sets of records to a List 4) Note that records without a 300$c will display a number at the end of the "Publication" description/string. It should be something like 33 or 34 in most cases. 5) Note that records with a 300$c don't display this number. They just show the value from 300$c. Apply the patch. 6) Clear your cache, refresh the page, etc. 7) Note that the number (e.g. 33 or 34) has disappeared from the end of the "Publication" description/string. Signed-off-by: Marcel de Rooy Added a small comment at the end of this one line. --- C4/VirtualShelves/Page.pm | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/C4/VirtualShelves/Page.pm b/C4/VirtualShelves/Page.pm index f393cb1..dd7d5f4 100644 --- a/C4/VirtualShelves/Page.pm +++ b/C4/VirtualShelves/Page.pm @@ -275,6 +275,7 @@ sub shelfpage { $this_item->{'normalized_ean'} = GetNormalizedEAN( $record,$marcflavour); $this_item->{'normalized_oclc'} = GetNormalizedOCLCNumber($record,$marcflavour); $this_item->{'normalized_isbn'} = GetNormalizedISBN(undef,$record,$marcflavour); + if(!defined($this_item->{'size'})) { $this_item->{'size'} = "" }; #TT has problems with size # Getting items infos for location display my @items_infos = &GetItemsLocationInfo( $this_item->{'biblionumber'}); $this_item->{'itemsissued'} = CountItemsIssued( $this_item->{'biblionumber'} ); -- 1.7.7.6