Bug 13268 - biblioitems.size value not correctly displayed (more)
Summary: biblioitems.size value not correctly displayed (more)
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Fridolin SOMERS
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-17 15:31 UTC by Fridolin SOMERS
Modified: 2015-12-03 22:02 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 13268 - biblioitems.size value not correctly displayed (more) (5.67 KB, patch)
2014-11-17 15:33 UTC, Fridolin SOMERS
Details | Diff | Splinter Review
Bug 13268 - biblioitems.size value not correctly displayed (more) (5.74 KB, patch)
2014-12-11 08:52 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13268: the size should not be emptied in pl script (1.00 KB, patch)
2014-12-11 08:52 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13268 - biblioitems.size value not correctly displayed (more) (5.79 KB, patch)
2014-12-28 04:47 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 13268: the size should not be emptied in pl script (1.06 KB, patch)
2014-12-28 04:47 UTC, Chris Cormack
Details | Diff | Splinter Review
[PASSED QA] Bug 13268 - biblioitems.size value not correctly displayed (more) (5.86 KB, patch)
2014-12-28 09:11 UTC, Katrin Fischer
Details | Diff | Splinter Review
[PASSED QA] Bug 13268: the size should not be emptied in pl script (1.13 KB, patch)
2014-12-28 09:11 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fridolin SOMERS 2014-11-17 15:31:06 UTC
Bug partially corrected by Bug 11357.

The size column in biblioitems is a bit problematic when used in TT, because instead of the size value from the biblio column it will give you the size of the variable or current loop.

It's currently used in the templates like opac-topissues.tt :
[% IF results_loo.size %][% results_loo.size %][% END %]

This patch corrects by using item() TT method.
See http://stackoverflow.com/questions/2311303/how-can-i-handle-hash-keys-containing-illegal-identifier-characters-in-template.

Test plan :
- Be sure there is a mapping between a MARC field and biblioitems.size
- Create a record A with biblioitems.size defined : like "10x12"
- Create a record B with no value in biblioitems.size
- Check each modified page :
=> Without this patch : you see a number (loop size) for both records
=> With this patch : you only see the correct value for A and nothing for B
Comment 1 Fridolin SOMERS 2014-11-17 15:31:52 UTC
Looks like it linked to Bug 11692
Comment 2 Fridolin SOMERS 2014-11-17 15:33:39 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2014-12-10 14:39:18 UTC
Against master:

cataloguing/addbooks.pl?q=tintin

I got:
 Les Aventures de Tintin. 15 : Objectif Lune

[texte et dessins] par Hergé - 2203001151 - 1981 - Casterman - 61 p. ; 30 cm 


biblioitems.size is mapped with 215$d and is equal to '30 cm'.

So what does this patch fix?
Comment 4 Fridolin SOMERS 2014-12-10 16:48:36 UTC
(In reply to Jonathan Druart from comment #3)

You reproduce the bug in opac-shelves.pl and opac-topissues.pl ?
Comment 5 Fridolin SOMERS 2014-12-10 16:59:06 UTC
(In reply to Jonathan Druart from comment #3)
> Against master:
> 
> cataloguing/addbooks.pl?q=tintin
> 
> I got:
>  Les Aventures de Tintin. 15 : Objectif Lune
> 
> [texte et dessins] par Hergé - 2203001151 - 1981 - Casterman - 61 p. ; 30 cm 
> 
> 
> biblioitems.size is mapped with 215$d and is equal to '30 cm'.
> 
> So what does this patch fix?

In this page, it works because of ugly hack in cataloguing/addbooks.pl :

    foreach my $line (@newresults) {
        if ( not exists $line->{'size'} ) { $line->{'size'} = "" }
    }

Looks like resultsloo.size is the size of loop only when biblioitems.size is undefined.
Comment 6 Jonathan Druart 2014-12-11 08:52:44 UTC Comment hidden (obsolete)
Comment 7 Jonathan Druart 2014-12-11 08:52:48 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2014-12-11 08:53:15 UTC
This is quite annoying because a value is displayed, but not the good one!
Comment 9 Chris Cormack 2014-12-28 04:47:38 UTC Comment hidden (obsolete)
Comment 10 Chris Cormack 2014-12-28 04:47:51 UTC Comment hidden (obsolete)
Comment 11 Katrin Fischer 2014-12-28 09:11:07 UTC
Created attachment 34757 [details] [review]
[PASSED QA] Bug 13268 - biblioitems.size value not correctly displayed (more)

Bug partially corrected by Bug 11357.

The size column in biblioitems is a bit problematic when used in TT, because instead of the size value from the biblio column it will give you the size of the variable or current loop.

It's currently used in the templates like opac-topissues.tt :
[% IF results_loo.size %][% results_loo.size %][% END %]

This patch corrects by using item() TT method.
See http://stackoverflow.com/questions/2311303/how-can-i-handle-hash-keys-containing-illegal-identifier-characters-in-template.

Test plan :
- Be sure there is a mapping between a MARC field and biblioitems.size
- Create a record A with biblioitems.size defined : like "10x12"
- Create a record B with no value in biblioitems.size
- Check each modified page :
=> Without this patch : you see a number (loop size) for both records
=> With this patch : you only see the correct value for A and nothing for B

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 12 Katrin Fischer 2014-12-28 09:11:31 UTC
Created attachment 34758 [details] [review]
[PASSED QA] Bug 13268: the size should not be emptied in pl script

It duplicates what the first patch does.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 13 Tomás Cohen Arazi 2015-02-05 17:59:20 UTC
Patches pushed to master.

Thanks Frido and Jonathan!
Comment 14 Chris Cormack 2015-02-09 20:52:55 UTC
Pushed to 3.18.x will be in 3.18.4
Comment 15 Mason James 2015-02-26 03:11:24 UTC
Possible selection for 3.16.x
Comment 16 Mason James 2015-04-22 10:06:16 UTC
Pushed to 3.16.x, will be in 3.16.10