[Koha-bugs] [Bug 8175] Check for something in materials field fails in catalogue/details.pl

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8175

--- Comment #11 from M. Tompsett <mtompset at hotmail.com> ---
Okay, I finally have time to get back to this.

I first found this because my materials fields were all NULL.
mysql -u {kohauser} -p
> use {koha database};
> select distinct materials from items;
+-----------+
| materials |
+-----------+
| NULL      |
+-----------+
1 row in set (0.17 sec)

So, I fixed the bug, and then Ian piped up about 0. So, I decided to break it
back to normal and test BEFORE the patch, and AFTER the patch.

TESTING
======
1) Log into Staff Client
2) Do a search to find an item
3) Click an item, and we should be at the detail.pl page for a biblionumber
(eg. 19158).

CASE NULL
=========
4) Go back to mysql and:
    update items SET materials=NULL where biblionumber=19158;
5) Go back to browser and refresh:
    There is no "Materials Specified" column displayed.
6) Check koha-error_log
[Sun Sep 02 16:08:38 2012] [error] [client 192.168.100.2] [Sun Sep  2 16:08:38
2012] detail.pl: Use of uninitialized value in string ne at
/usr/share/koha/intranet/cgi-bin/catalogue/detail.pl line 255., referer:
https://.../cgi-bin/koha/catalogue/search.pl?q=the

CASE 0
======
7) Go back to mysql and:
    update items SET materials='0' where biblionumber=19158;
8) Go back to browser and refresh:
    There is a "Materials Specified" column with 0 displayed in it.
9) Check error log again. Nothing new.

CASE ''
=======
10) Go back to mysql and:
    update items SET materials='' where biblionumber=19158;
11) Go back to browser and refresh:
    There is no "Materials Specified" column displayed.
12) Check error log again. Nothing new.

CASE ' '
========
13) Go back to mysql and:
    update items SET materials='0' where biblionumber=19158;
14) Go back to browser and refresh:
    There is a "Materials Specified" column with nothing visible in it.
15) Check error log again. Nothing new.

CASE 'blah'
======
7) Go back to mysql and:
    update items SET materials='blah' where biblionumber=19158;
8) Go back to browser and refresh:
    There is a "Materials Specified" column with blah displayed in it.
9) Check error log again. Nothing new.

There are two things wrong: 1) the generated error, which caused me to find
this bug, and 2) showing a column for no apparent reason.

| CASE   | Defined | =~ /\S/ | $var | ne '' | Should Display? | Display? |
+========+=========+=========+======+=======+=================+==========+
| NULL   | 0       | Error   | 0    | Error | 0               | 0        |
| ''     | 1       | 0       | 0    | 0     | 0               | 0        |
| '0'    | 1       | 1       | 0    | 1     | 1               | 1        |
| ' '    | 1       | 0       | 1    | 1     | 0               | 1        |
| 'blah' | 1       | 1       | 1    | 1     | 1               | 1        |
+========+=========+=========+======+=======+=================+==========+

The above table shows 1/0 values for potential replacement code or existing
code options, and whether or not it displays correctly.

Patch and repeat the test cases. Once you are finished, you may wish to set
your materials value back to what it was.

Seeing as materials is a 'text' type, the 0 vs. '0' difference is irrelevant.
But I hope this table and test plan explains what I was thinking when I wrote
those comments. I'll have patches up shortly.

-- 
You are receiving this mail because:
You are watching all bug changes.