[Bug 32804] New: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Bug ID: 32804 Summary: Importing and replacing items causes inconsistency when itemnumber match and biblio match disagree Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org When 'Item processing' option during import is set to 'replace' itemnumber matches do not check any other data - so the item's biblionumber is set to the matched biblionumber, but the biblioitemnumber is not updated or checked This means that if you import a record containing an item with an itemnumber from another record you will end up with an item with mismatched biblio and biblioitem numbers This happens in consortia when multiple libraries have ordered the same biblio. Two biblios are created, later the final import with barcodes etc. is imported to replace items, and the more full bib is chosen for the biblio match, so items are half moved. To recreate: 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |critical -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #1 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 146034 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146034&action=edit Sample file for importing with item from another record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #2 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 146037 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146037&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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewfh@dubcolib.org Status|Needs Signoff |Failed QA --- Comment #3 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- At step 20 in the test plan I'm not getting an item created as described. I have deleted the item with barcode 39999000004090, but when I stage the batch set to match on biblionumber and replace items I don't get a new item created on import. The import_items table gives the error "duplicate item barcode" even though that barcode is in deleteditems and doesn't bring anything up in searches. Also, the behavior at steps 16/17 seems wrong to me. The incoming MARC has this item on one bib, Koha has it on another. To my mind, that suggests there's some fundamental confusion that should be sorted out manually. With this patch as written, the import and overlay edits an item on a bib that's not indicated in any way when looking at the batch, which seems like a good way miss errors in your import batch and to introduce unexpected item edits to your catalog. The item action choice is "Replace items when a matching bib is found." This is replacing an item on a non-matching bib. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #146037|0 |1 is obsolete| | --- Comment #4 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 146292 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146292&action=edit Bug 32804: Add unit tests -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #5 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 146293 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146293&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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #6 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Andrew Fuerste-Henry from comment #3)
At step 20 in the test plan I'm not getting an item created as described. I have deleted the item with barcode 39999000004090, but when I stage the batch set to match on biblionumber and replace items I don't get a new item created on import. The import_items table gives the error "duplicate item barcode" even though that barcode is in deleteditems and doesn't bring anything up in searches.
I did not have this experience when I attempted to reproduce the issue from your description. Everything worked as Nick described.
Also, the behavior at steps 16/17 seems wrong to me. The incoming MARC has this item on one bib, Koha has it on another. To my mind, that suggests there's some fundamental confusion that should be sorted out manually. With this patch as written, the import and overlay edits an item on a bib that's not indicated in any way when looking at the batch, which seems like a good way miss errors in your import batch and to introduce unexpected item edits to your catalog. The item action choice is "Replace items when a matching bib is found." This is replacing an item on a non-matching bib.
I can understand your pov, but I also think catalogers care less about which bib the item is attached to and much more about having the item overlay correctly. My experience is that they overlay the records and items, then merge all duplicate records. We may want to adjust the wording of that message to clarify that it overlays items if *any* record matches. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #146292|0 |1 is obsolete| | Attachment #146293|0 |1 is obsolete| | --- Comment #7 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 146345 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146345&action=edit Bug 32804: Add unit tests -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 146346 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146346&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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |32901 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32901 [Bug 32901] Replace use of the slang term "bib" with the term "record" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #9 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- (In reply to Kyle M Hall from comment #6)
(In reply to Andrew Fuerste-Henry from comment #3)
At step 20 in the test plan I'm not getting an item created as described. I have deleted the item with barcode 39999000004090, but when I stage the batch set to match on biblionumber and replace items I don't get a new item created on import. The import_items table gives the error "duplicate item barcode" even though that barcode is in deleteditems and doesn't bring anything up in searches.
I did not have this experience when I attempted to reproduce the issue from your description. Everything worked as Nick described.
I've just tested this again with the same result. The item with barcode 39999000004090 has been deleted but I get an import_error of "duplicate barcode' when importing the sample batch from this bug set to match on biblionumber and replace items. No new item is created. Having read through the test plan several times, I'm stumped. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #10 from Kyle M Hall <kyle@bywatersolutions.com> ---
I've just tested this again with the same result. The item with barcode 39999000004090 has been deleted but I get an import_error of "duplicate barcode' when importing the sample batch from this bug set to match on biblionumber and replace items. No new item is created. Having read through the test plan several times, I'm stumped.
I retested and I'm failing on step 20. Is that where you are having your issue as well? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #11 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- (In reply to Kyle M Hall from comment #10)
I've just tested this again with the same result. The item with barcode 39999000004090 has been deleted but I get an import_error of "duplicate barcode' when importing the sample batch from this bug set to match on biblionumber and replace items. No new item is created. Having read through the test plan several times, I'm stumped.
I retested and I'm failing on step 20. Is that where you are having your issue as well?
Yes, at step 20 I don't get an item created. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #146346|0 |1 is obsolete| | --- Comment #12 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 146579 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146579&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 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #13 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Andrew Fuerste-Henry from comment #11)
(In reply to Kyle M Hall from comment #10)
I've just tested this again with the same result. The item with barcode 39999000004090 has been deleted but I get an import_error of "duplicate barcode' when importing the sample batch from this bug set to match on biblionumber and replace items. No new item is created. Having read through the test plan several times, I'm stumped.
I retested and I'm failing on step 20. Is that where you are having your issue as well?
Yes, at step 20 I don't get an item created.
I had an uncommitted change on my local machine, patches updated, please test again -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #146345|0 |1 is obsolete| | Attachment #146579|0 |1 is obsolete| | --- Comment #14 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 147134 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147134&action=edit Bug 32804: Add unit tests JD amended patch - is( $item1->homebranch, $library->branchcode, "Item was overlayed succesfully" ); + is( $item1->homebranch, $library->branchcode, "Item was overlaid successfully" ); -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #15 from Jonathan Druart <jonathan.druart+koha@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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147134|0 |1 is obsolete| | --- Comment #16 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- Created attachment 147668 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147668&action=edit Bug 32804: Add unit tests JD amended patch - is( $item1->homebranch, $library->branchcode, "Item was overlayed succesfully" ); + is( $item1->homebranch, $library->branchcode, "Item was overlaid successfully" ); Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147135|0 |1 is obsolete| | --- Comment #17 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- Created attachment 147669 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147669&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 Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl Status|Signed Off |Failed QA --- Comment #18 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- # Subtest: Do not adjust biblionumber when replacing items during import 1..6 ok 1 - Item's homebranch is currently not the same as our created branch's branchcode ok 2 - Item was replaced ok 3 - Import was successful ok 4 - No error was reported not ok 5 - Item's biblionumber and biblioitemnumber match # Failed test 'Item's biblionumber and biblioitemnumber match' # at t/db_dependent/ImportBatch.t line 404. # # got: '3899' # expected: '2138' # -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |m.de.rooy@rijksmuseum.nl |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #19 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 147690 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147690&action=edit Bug 32804: (follow-up) Test that id's have not changed Rather than assuming biblionumber and biblioitemnumber are the same, we should test that they have not changed form their original values -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kyle@bywatersolutions.com |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |BLOCKED --- Comment #20 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Looking here -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Passed QA Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147668|0 |1 is obsolete| | --- Comment #21 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 148314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148314&action=edit Bug 32804: Add unit tests JD amended patch - is( $item1->homebranch, $library->branchcode, "Item was overlayed succesfully" ); + is( $item1->homebranch, $library->branchcode, "Item was overlaid successfully" ); Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147669|0 |1 is obsolete| | --- Comment #22 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 148315 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148315&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 Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147690|0 |1 is obsolete| | --- Comment #23 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 148316 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148316&action=edit Bug 32804: (follow-up) Test that id's have not changed Rather than assuming biblionumber and biblioitemnumber are the same, we should test that they have not changed form their original values Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #24 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 148317 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148317&action=edit Bug 32804: (QA follow-up) Typo ahs and fix ImportBatch.t Resolve: # Failed test 'Item's biblioitemnumber has not changed' # at t/db_dependent/ImportBatch.t line 407. # # got: '4261' # expected: '2371' Do not compare $item1->biblionumber with $original_biblioitemnumber :) Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |23.05.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #25 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Pushed to master for 23.05. Nice work everyone, thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|23.05.00 |23.05.00,22.11.04 released in| | Status|Pushed to master |Pushed to stable -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #26 from Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> --- Nice work everyone! Pushed to stable for 22.11.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #27 from Lucas Gass <lucas@bywatersolutions.com> --- Merge conflicts with 22.05.x, no backport. If needed please rebase. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #28 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 150363 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150363&action=edit Bug 32804: [22.05.x] 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 Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Bug 32804: Add unit tests JD amended patch - is( $item1->homebranch, $library->branchcode, "Item was overlayed succesfully" ); + is( $item1->homebranch, $library->branchcode, "Item was overlaid successfully" ); Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Bug 32804: (follow-up) Test that id's have not changed Rather than assuming biblionumber and biblioitemnumber are the same, we should test that they have not changed form their original values Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Bug 32804: (QA follow-up) Typo ahs and fix ImportBatch.t Resolve: # Failed test 'Item's biblioitemnumber has not changed' # at t/db_dependent/ImportBatch.t line 407. # # got: '4261' # expected: '2371' Do not compare $item1->biblionumber with $original_biblioitemnumber :) Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32804 --- Comment #29 from Nick Clemens <nick@bywatersolutions.com> --- (In reply to Lucas Gass from comment #27)
Merge conflicts with 22.05.x, no backport. If needed please rebase.
Patch rebased, please test before pushing -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org