Bug 2466 - can't remove value in item modif
Summary: can't remove value in item modif
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: rel_3_2
Hardware: PC All
: PATCH-Sent (DO NOT USE) blocker
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-05 03:56 UTC by Paul Poulain
Modified: 2019-06-27 09:24 UTC (History)
1 user (show)

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


Attachments

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


---- Reported by paul.poulain@biblibre.com 2008-08-05 03:56:10 ----

If you enter a value in a field that is mapped to a items.field, you can't remove the value here after.

Investigating the code, it appears that additem.pl calls ModItemFromMarc
ModItemFromMarc calls calls ModItem
ModItem calls _koha_modify_item

_koha_modify_item UPDATE only fields that have a value. fields that have no values remains unchanged.

Possible solution = don't use
>     for my $key ( keys %$item ) {
but hardcode all items fields.

This could have some side effect, so is that a correct solution ? I'm not completly sure. Let me know if you have an idea...



---- Additional Comments From joe.atzberger@liblime.com 2008-08-08 08:50:31 ----

Without disputing the symptom reported, I disagree that _koha_modify_item only updates populated values.

...
    my $query = "UPDATE items SET ";
    my @bind;
    for my $key ( keys %$item ) {
        $query.="$key=?,";
        push @bind, $item->{$key};
    }
    $query =~ s/,$//;
    $query .= " WHERE itemnumber=?";
    push @bind, $item->{'itemnumber'};
    my $sth = C4::Context->dbh->prepare($query);
    $sth->execute(@bind);
...

So _koha_modify_item will modify values to empty-string if they are passed, i.e.:

$item = { itemnumber=>531, field_x=>"", field_y=""};

ModItem also does not filter down the fields passed except to ensure cn.sort is calculated, and notforloan/damaged/itemlost/wthdrawn are 0 instead of "" or undef.

That leaves ModItemFromMarc as the remaining suspect.  It uses TransformMarcToKoha and _get_unlinked_item_subfields.



---- Additional Comments From jmf@liblime.com 2008-08-08 13:02:29 ----

This is going to be a known issue with 3.0 for now, bumping to 3.2, perhaps we can back-port it to 3.0.



---- Additional Comments From gmcharlt@gmail.com 2008-08-26 07:37:07 ----

*** http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2554 has been marked as a duplicate of this bug. ***



---- Additional Comments From gmcharlt@gmail.com 2008-08-26 08:33:17 ----

Patch submitted.



---- Additional Comments From gmcharlt@gmail.com 2008-08-28 07:35:33 ----

Patch pushed.  Please test in 3.1.



---- Additional Comments From gmcharlt@gmail.com 2009-05-01 12:41:30 ----

Paul - is this still a problem in HEAD or 3.0.x?



---- Additional Comments From chris@bigballofwax.co.nz 2009-12-12 09:56:26 ----

Can not reproduce this, marking it as fixed



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC  ---

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

Actual time not defined. Setting to 0.0
CC member debra.denault@liblime.com does not have an account here