[Koha-bugs] [Bug 32804] Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804

--- Comment #15 from Jonathan Druart <jonathan.druart+koha at gmail.com> ---
Created attachment 147135
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147135&action=edit
Bug 32804: Do not adjust biblionumber when replacing items during import

This patch adjust the item matching at import to confirm that for a duplicate
itemnumber or barcode
matches an existing item in the DB and uses the original biblionumber when
updating the item.

When ordering in a consortium the items may be moved around, duplicate biblios
added, and various matches found.
We should not allow importing of items to move them from 1 biblio to another,
but  we should allow the imports
to succeed and assume itemnumber or barcode matches are authoritative. The
responsibility for correct matching of items to biblio should fall on the
creator of the files

To test:
 1 - Be using the sample data in koha testing docker
 2 - Stage the sample file on this report
 3 - Match on KohaBiblio(999$c) / Item processing: replace
 4 - Note the biblio match is "The complete novels / Austen, Jane"
 5 - View the staged marc, note the barcode 39999000004090 in an item
 6 - Search for that barcode
 7 - You find biblio "Five novels : complete and unabridged / Gustave Flaubert"
 8 - Import the file
 9 - Check the db:
     SELECT * FROM items WHERE biblionumber != biblioitemnumber;
10 - Note the mismatch
11 - Fix the item and set it as 'Music' type
     UPDATE items SET biblionumber = biblioitemnumber, itype='MU' WHERE
biblionumber != biblioitemnumber;
12 - Apply patch, restart all
13 - Stage and import the file with the same settings
14 - Confirm the item is modified on its original biblio (99) and that item
type is Book again
15 - Change itemnumber to avoid itemnumber match and reset type
     UPDATE items SET itype='MU', itemnumber=999 WHERE itemnumber=212;
16 - Stage and import with the same setttings
17 - Confirm the marcode match worked and item is updated to book on original
record
18 - Delete the original item
19 - Stage and import the file with the same settings
20 - The item is successfully created
21 - Stage and import, but item processing option is 'add'
22 - Confirm 1 item ignored
23 - Check the db
     SELECT * FROM import_items WHERE barcode=39999000004090
24 - Confirm there is a line with 'error' and duplicate_barcode

JD amended patch
-        # We assume that when replaicing tiems we do not want to move them -
the onus is on the importer to
+        # We assume that when replacing items we do not want to move them -
the onus is on the importer to

-- 
You are receiving this mail because:
You are watching all bug changes.