From d46581b8f0499fe7353204d732f78e8465fa10c5 Mon Sep 17 00:00:00 2001 From: Galen Charlton Date: Wed, 12 Dec 2007 15:27:46 -0600 Subject: [PATCH] bugfix: do not try to set items.cn_sort twice The way this API is used by additem.pl, the $item hasref already contains a 'items.cn_sort' key whose value is undef. Setting $item->{'cn_sort'} instead of $item->{'items.cn_sort'} ends putting with items.cn_sort and cn_sort in the UPDATE items statement, making the final value of cn_sort in the DB dependent on the order produced by Perl's keys function. Also added a comment explaining a subtle (perhaps too subtle) point in the code. Signed-off-by: Joshua Ferraro --- C4/Biblio.pm | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/C4/Biblio.pm b/C4/Biblio.pm index ecd5fcaf71..a96344f7b3 100755 --- a/C4/Biblio.pm +++ b/C4/Biblio.pm @@ -3906,7 +3906,18 @@ sub _koha_modify_item { # calculate items.cn_sort if($item->{'itemcallnumber'}) { - $item->{'cn_sort'} = GetClassSort($item->{'items.cn_source'}, $item->{'itemcallnumber'}, ""); + # This works, even when user is setting the call number blank (in which case + # how would we get here to calculate new (blank) of items.cn_sort?). + # + # Why? Because at present the only way to update itemcallnumber is via + # additem.pl; since it uses a MARC data-entry form, TransformMarcToKoha + # already has created $item->{'items.cn_sort'} and set it to undef because the + # subfield for items.cn_sort in the framework is specified as ignored, meaning + # that it is not supplied or passed to the form. Thus, if the user has + # blanked itemcallnumber, there is already a undef value for $item->{'items.cn_sort'}. + # + # This is subtle; it is also fragile. + $item->{'items.cn_sort'} = GetClassSort($item->{'items.cn_source'}, $item->{'itemcallnumber'}, ""); } my $query = "UPDATE items SET "; my @bind; -- 2.39.5