Bug 11399

Hi Stephane, I am a bit confused about the use of this, because I think we don't keep the item information in the MARC any more?

(In reply to Katrin Fischer from comment #2)
> Hi Stephane, I am a bit confused about the use of this, because I think we
> don't keep the item information in the MARC any more?

Hi Katrin, in fact, informations about items aren't stored directly in MARC. However, when editing a record, MARC items informations can be regenerated temporarily (that's what serves '1' when we call the function 'GetMarcBiblio($biblionumber,1)'). When a mapping is changed in "MARC bibliographic framework" or "Koha to MARC mapping" (admin/koha2marclinks.pl on items), it does not change the existing items. For example in UNIMARC, without this patch, if I want to link the 995$j with items.stocknumber, this information will remain in items.more_subfields_xml for old items as long as they have not been modified manually. This script forces rewriting of items taking new mapping into account (in our example, all 995$j will then be moved from items.more_subfields_xml to items.stocknumber).

Hi Stephane, that makes sense - maybe we should change the bug description? I think this will only be needed if you change the mapping from a before unmapped field or when you map an unmapped one (more_subfields_xml)

Comment on attachment 29156 [details] [review]
[SIGNED-OFF] Bug 11399: batch Rebuild Items Tables

Review of attachment 29156 [details] [review]:
-----------------------------------------------------------------

2 small things from code review:

::: misc/batchRebuildItemsTables.pl
@@ +1,4 @@
> +#!/usr/bin/perl
> +use 5.10.0;
> +use strict;
> +use warnings;

Please switch to: use Modern::Perl; :)

@@ +94,5 @@
> +    }
> +}
> +
> +$dbh->do("UPDATE systempreferences SET value=$CataloguingLog WHERE variable='CataloguingLog'");
> +$dbh->do("UPDATE systempreferences SET value=$dontmerge where variable='dontmerge'");

Please switch to using placeholders instead of variables.

Created attachment 32511 [details] [review]
[PASSED QA] Bug 11399: batch Rebuild Items Tables

You can/must use it when you change items mapping.
this script rebuilds the non-MARC DB items table from the MARC values

usage : batchRebuildItemsTables.pl [ -h ][ -c ][ -t ][ -where ]

Options:
   -h --help       (or without arguments) shows this help message
   -c              Confirm: rebuild non marc DB (may be long)
   -t              test only, change nothing in DB
   --where         add where condition on default query
                   (eg. -where 'biblio.biblionumber<100')

(copied test plan)
to test it :

create a test item (eg on biblionumber 3) with a non mapped subfield with a test value.
check real items DB row ( SELECT * from items where biblionumber=3 ) => non mapped value is in more_subfields_xml
map the non mapped subfield with unused items column
re-check in Db that nothing changes
run ./batchRebuildItemsTables.pl -c --where 'biblio.biblionumber=3'
check real items DB row ( SELECT * from items where biblionumber=3 ) => new mapped value is not in more_subfields_xml anymore but in the mapped column

Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Work as described, no koha-qa errors.
Add a new item to record, save with value in unmapped subfield ('x')
Change mapping, run script, value on newly mapped column

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Created attachment 32512 [details] [review]
[PASSED QA] Bug 11399: QA fixes

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Note, I found it a bit confusing that a test run required both -t *and* -c. I would expect each to be independent, and use of both would be the same as -t alone. However, we have no formal guidelines for this yet, so I do not feel it is proper to fail qa on this point.

Patches pushed to master.

Thanks Stephane!