http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 --- Comment #1 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 37412 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37412&action=edit Bug 13934: C4::ItemType->get should return undef if no parameter given The issue: If you try to check in an item with a non existent barcode, the application will exploded with a software error: "Can't bless non-reference at .../ItemType.pm Line 64". It's caused by: commit 7431f8cfe29e330e2232b0df591afc4d923b0a52 Bug 11944: Fix encoding issue in C4::ItemType and the following change: @@ -105,9 +104,6 @@ sub get { my $data = $dbh->selectrow_hashref( "SELECT * FROM itemtypes WHERE itemtype = ?", undef, $itemtype ); - if ( $data->{description} ) { - $data->{description} = Encode::encode('UTF-8', $data->{description}); - } because of the following: my $s; $s->{foo} = "bar" if $s->{foo}; use Data::Dumper;warn Dumper $s; => {} # not undef So later, bless $opts => $class; will fail because $opts is undef and was not (i.e. {}) before. Test plan: Try to check in an item with a non existent barcode and confirm you have the friendly warning message instead of the ugly software error. Note for QA: C4::ItemType->get is only uses in circ/return.pl. So even if the behavior is changed, it should not introduce any regression somewhere else. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 --- Comment #2 from M. Tompsett <mtompset@hotmail.com> --- Comment on attachment 37412 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37412 Bug 13934: C4::ItemType->get should return undef if no parameter given Review of attachment 37412: --> (http://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=13934&attachment=37412) ----------------------------------------------------------------- ::: C4/ItemType.pm @@ +99,5 @@

sub get { my ($class, $itemtype) = @_; + + return unless $itemtype;

Hypothetical question: Could not someone do something crazy like have an itemtype code of 0? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #37412|0 |1 is obsolete| | --- Comment #3 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 37427 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37427&action=edit Bug 13934: C4::ItemType->get should return undef if no parameter given The issue: If you try to check in an item with a non existent barcode, the application will exploded with a software error: "Can't bless non-reference at .../ItemType.pm Line 64". It's caused by: commit 7431f8cfe29e330e2232b0df591afc4d923b0a52 Bug 11944: Fix encoding issue in C4::ItemType and the following change: @@ -105,9 +104,6 @@ sub get { my $data = $dbh->selectrow_hashref( "SELECT * FROM itemtypes WHERE itemtype = ?", undef, $itemtype ); - if ( $data->{description} ) { - $data->{description} = Encode::encode('UTF-8', $data->{description}); - } because of the following: my $s; $s->{foo} = "bar" if $s->{foo}; use Data::Dumper;warn Dumper $s; => {} # not undef So later, bless $opts => $class; will fail because $opts is undef and was not (i.e. {}) before. More explicit test plan: 1) Log in to staff client 2) Circulation -> Check in 3) Type a non-existent barcode into 'Enter item barcode:' textbox 4) Click 'Submit' -- Should receive nasty error. 5) apply patch 6) repeat steps 2-4 -- Should be told 'No item with barcode: {what you typed}' 7) prove -v t/ItemType.t -- All tests should run successfully. 7) run koha qa test tools Note: Having tried to create and use an itemtype '0', this only demonstrates a lack of validation on the itemtype creation screen. Unable to use it without tweaking back end. That is beyond the scope of this bug. Note for QA: C4::ItemType->get is only uses in circ/return.pl. So even if the behavior is changed, it should not introduce any regression somewhere else. Signed-off-by: Mark Tompsett <mtompset@hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #37427|0 |1 is obsolete| | --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 37452 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37452&action=edit [PASSED QA] Bug 13934: C4::ItemType->get should return undef if no parameter given The issue: If you try to check in an item with a non existent barcode, the application will exploded with a software error: "Can't bless non-reference at .../ItemType.pm Line 64". It's caused by: commit 7431f8cfe29e330e2232b0df591afc4d923b0a52 Bug 11944: Fix encoding issue in C4::ItemType and the following change: @@ -105,9 +104,6 @@ sub get { my $data = $dbh->selectrow_hashref( "SELECT * FROM itemtypes WHERE itemtype = ?", undef, $itemtype ); - if ( $data->{description} ) { - $data->{description} = Encode::encode('UTF-8', $data->{description}); - } because of the following: my $s; $s->{foo} = "bar" if $s->{foo}; use Data::Dumper;warn Dumper $s; => {} # not undef So later, bless $opts => $class; will fail because $opts is undef and was not (i.e. {}) before. More explicit test plan: 1) Log in to staff client 2) Circulation -> Check in 3) Type a non-existent barcode into 'Enter item barcode:' textbox 4) Click 'Submit' -- Should receive nasty error. 5) apply patch 6) repeat steps 2-4 -- Should be told 'No item with barcode: {what you typed}' 7) prove -v t/ItemType.t -- All tests should run successfully. 7) run koha qa test tools Note: Having tried to create and use an itemtype '0', this only demonstrates a lack of validation on the itemtype creation screen. Unable to use it without tweaking back end. That is beyond the scope of this bug. Note for QA: C4::ItemType->get is only uses in circ/return.pl. So even if the behavior is changed, it should not introduce any regression somewhere else. Signed-off-by: Mark Tompsett <mtompset@hotmail.com> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #37452|0 |1 is obsolete| | --- Comment #5 from Jonathan Druart <jonathan.druart@biblibre.com> --- Created attachment 37536 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37536&action=edit Bug 13934: C4::ItemType->get should return undef if no parameter given The issue: If you try to check in an item with a non existent barcode, the application will exploded with a software error: "Can't bless non-reference at .../ItemType.pm Line 64". It's caused by: commit 7431f8cfe29e330e2232b0df591afc4d923b0a52 Bug 11944: Fix encoding issue in C4::ItemType and the following change: @@ -105,9 +104,6 @@ sub get { my $data = $dbh->selectrow_hashref( "SELECT * FROM itemtypes WHERE itemtype = ?", undef, $itemtype ); - if ( $data->{description} ) { - $data->{description} = Encode::encode('UTF-8', $data->{description}); - } because of the following: my $s; $s->{foo} = "bar" if $s->{foo}; use Data::Dumper;warn Dumper $s; => {} # not undef So later, bless $opts => $class; will fail because $opts is undef and was not (i.e. {}) before. More explicit test plan: 1) Log in to staff client 2) Circulation -> Check in 3) Type a non-existent barcode into 'Enter item barcode:' textbox 4) Click 'Submit' -- Should receive nasty error. 5) apply patch 6) repeat steps 2-4 -- Should be told 'No item with barcode: {what you typed}' 7) prove -v t/ItemType.t -- All tests should run successfully. 7) run koha qa test tools Note: Having tried to create and use an itemtype '0', this only demonstrates a lack of validation on the itemtype creation screen. Unable to use it without tweaking back end. That is beyond the scope of this bug. Note for QA: C4::ItemType->get is only uses in circ/return.pl. So even if the behavior is changed, it should not introduce any regression somewhere else. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13934 --- Comment #7 from Josef Moravec <josef.moravec@gmail.com> --- Created attachment 37558 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37558&action=edit [SIGNED-OFF] Bug 13934: C4::ItemType->get should return undef if no parameter given The issue: If you try to check in an item with a non existent barcode, the application will exploded with a software error: "Can't bless non-reference at .../ItemType.pm Line 64". It's caused by: commit 7431f8cfe29e330e2232b0df591afc4d923b0a52 Bug 11944: Fix encoding issue in C4::ItemType and the following change: @@ -105,9 +104,6 @@ sub get { my $data = $dbh->selectrow_hashref( "SELECT * FROM itemtypes WHERE itemtype = ?", undef, $itemtype ); - if ( $data->{description} ) { - $data->{description} = Encode::encode('UTF-8', $data->{description}); - } because of the following: my $s; $s->{foo} = "bar" if $s->{foo}; use Data::Dumper;warn Dumper $s; => {} # not undef So later, bless $opts => $class; will fail because $opts is undef and was not (i.e. {}) before. More explicit test plan: 1) Log in to staff client 2) Circulation -> Check in 3) Type a non-existent barcode into 'Enter item barcode:' textbox 4) Click 'Submit' -- Should receive nasty error. 5) apply patch 6) repeat steps 2-4 -- Should be told 'No item with barcode: {what you typed}' 7) prove -v t/ItemType.t -- All tests should run successfully. 7) run koha qa test tools Note: Having tried to create and use an itemtype '0', this only demonstrates a lack of validation on the itemtype creation screen. Unable to use it without tweaking back end. That is beyond the scope of this bug. Note for QA: C4::ItemType->get is only uses in circ/return.pl. So even if the behavior is changed, it should not introduce any regression somewhere else. Signed-off-by: Josef Moravec <josef.moravec@gmail.com> -- You are receiving this mail because: You are watching all bug changes.