C4 and misc: permissions fixes

[koha_ffzg] / C4 / Biblio.pm

diff --git a/C4/Biblio.pm b/C4/Biblio.pm
old mode 100755 (executable)
new mode 100644 (file)
index 7559ee2..a96344f
--- a/C4/Biblio.pm
+++ b/C4/Biblio.pm
@@ -1729,23 +1729,49 @@ Returns MARC::Record of the item passed in parameter.
 
 sub GetMarcItem {
     my ( $biblionumber, $itemnumber ) = @_;
-    my $dbh = C4::Context->dbh;
-    my $newrecord = MARC::Record->new();
-    my $marcflavour = C4::Context->preference('marcflavour');
-    
-    my $marcxml = GetXmlBiblio($biblionumber);
-    my $record = MARC::Record->new();
-    $record = MARC::Record::new_from_xml( $marcxml, "utf8", $marcflavour );
-    # now, find where the itemnumber is stored & extract only the item
-    my ( $itemnumberfield, $itemnumbersubfield ) =
-      GetMarcFromKohaField( 'items.itemnumber', '' );
-    my @fields = $record->field($itemnumberfield);
-    foreach my $field (@fields) {
-        if ( $field->subfield($itemnumbersubfield) eq $itemnumber ) {
-            $newrecord->insert_fields_ordered($field);
-        }
-    }
-    return $newrecord;
+
+    # GetMarcItem has been revised so that it does the following:
+    #  1. Gets the item information from the items table.
+    #  2. Converts it to a MARC field for storage in the bib record.
+    #
+    # The previous behavior was:
+    #  1. Get the bib record.
+    #  2. Return the MARC tag corresponding to the item record.
+    #
+    # The difference is that one treats the items row as authoritative,
+    # while the other treats the MARC representation as authoritative
+    # under certain circumstances.
+    #
+    # FIXME - a big one
+    #
+    # As of 2007-11-27, this change hopefully does not introduce
+    # any bugs.  However, it does mean that for code that uses
+    # ModItemInMarconefield to update one subfield (corresponding to
+    # an items column) is now less efficient.
+    #
+    # The API needs to be shifted to the following:
+    #  1. User updates items record.
+    #  2. Linked bib is sent for indexing.
+    # 
+    # The missing step 1.5 is updating the item tag in the bib MARC record
+    # so that the indexes are updated.  Depending on performance considerations,
+    # this may ultimately mean of of the following:
+    #  a. MARC field for item is updated right away.
+    #  b. MARC field for item is updated only as part of indexing.
+    #  c. MARC field for item is never actually stored in bib record; instead
+    #     it is generated only when needed for indexing, item export, and
+    #     (maybe) OPAC display.
+    #
+
+    my $itemrecord = GetItem($itemnumber);
+
+    # Tack on 'items.' prefix to column names so that TransformKohaToMarc will work.
+    # Also, don't emit a subfield if the underlying field is blank.
+    my $mungeditem = { map {  $itemrecord->{$_} ne '' ? ("items.$_" => $itemrecord->{$_}) : ()  } keys %{ $itemrecord } };
+
+    my $itemmarc = TransformKohaToMarc($mungeditem);
+    return $itemmarc;
+
 }
 
 
@@ -3058,8 +3084,10 @@ sub ModZebra {
         }
         if ($op eq 'specialUpdate') {
             # OK, we have to add or update the record
-            # 1st delete (virtually, in indexes) ...
-            %result = _DelBiblioNoZebra($biblionumber,$record,$server);
+            # 1st delete (virtually, in indexes), if record actually exists
+            if ($record) { 
+                %result = _DelBiblioNoZebra($biblionumber,$record,$server);
+            }
             # ... add the record
             %result=_AddBiblioNoZebra($biblionumber,$newRecord, $server, %result);
         } else {
@@ -3811,6 +3839,9 @@ sub _koha_new_items {
             paidfor            = ?,
                        location                        = ?,
                        onloan                          = ?,
+                       issues                          = ?,
+                       renewals                        = ?,
+                       reserves                        = ?,
                        cn_source                       = ?,
                        cn_sort                         = ?,
                        ccode                           = ?,
@@ -3841,6 +3872,9 @@ sub _koha_new_items {
                        $item->{'paidfor'},
                        $item->{'location'},
                        $item->{'onloan'},
+                       $item->{'issues'},
+                       $item->{'renewals'},
+                       $item->{'reserves'},
                        $item->{'items.cn_source'},
                        $items_cn_sort,
                        $item->{'ccode'},
@@ -3871,8 +3905,20 @@ sub _koha_modify_item {
        my $error;
 
        # calculate items.cn_sort
-    $item->{'cn_sort'} = GetClassSort($item->{'items.cn_source'}, $item->{'itemcallnumber'}, "");
-
+    if($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;
        for my $key ( keys %$item ) {
@@ -3881,7 +3927,7 @@ sub _koha_modify_item {
     }
        $query =~ s/,$//;
     $query .= " WHERE itemnumber=?";
-    push @bind, $item->{'itemnumber'};
+       push @bind, $item->{'itemnumber'};
     my $sth = $dbh->prepare($query);
     $sth->execute(@bind);
     if ( $dbh->errstr ) {