https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 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 the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 --- Comment #1 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 69804 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=69804&action=edit Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing MarcItemFieldsToOrder defines how Koha looks at tags in order records to generate item data. Let's look at a simplified case: homebranch: 955$a holdingbranch: 956$a So, here we are looking at 955 for the home branch, and 956 for the holding branch. So, it should make sense that Koha requires that these fields exist in equal number in the record. That is, for each 955, there should be a corresponding 956. Let's look at a different case: homebranch: 946$a|975$a holdingbranch: 946$a|975$a In this case, we are using the fallback behavior. VendorA stores the branch data in 946, and VendorB stores it in 975. This seems like it would work, but it won't! That's because Koha is expecting there to be the same number of 946's as there are 975's! In reality, the VendorA records will have a number of 946's, and *zero* 975's. The inverse will be true for VendorB. Koha should be able to skip those tags that simply don't exist in the record. Test Plan: 1) Set MarcItemFieldsToOrder to something like: homebranch: 946$a|975$a holdingbranch: 946$a|975$a budget_code: 946$f|975$f itype: 946$y|975$y notforloan: 946$l|975$l ccode: 946$t|975$c quantity: 946$q|975$q price: 946$p|975$p itemcallnumber: 946$n|975$n loc: 946$c|975$t 2) Create a record using only the 975 tag for item building data 3) Import the record into Koha 4) Create a basket 5) Attempt to add the record to the basket 6) Note the unequal fields error 7) Apply this patch 8) Reload the page 9) No error! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 Kyle M Hall <kyle@bywatersolutions.com> 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=19813 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl 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=19813 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #69830|0 |1 is obsolete| | --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 70110 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=70110&action=edit Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing MarcItemFieldsToOrder defines how Koha looks at tags in order records to generate item data. Let's look at a simplified case: homebranch: 955$a holdingbranch: 956$a So, here we are looking at 955 for the home branch, and 956 for the holding branch. So, it should make sense that Koha requires that these fields exist in equal number in the record. That is, for each 955, there should be a corresponding 956. Let's look at a different case: homebranch: 946$a|975$a holdingbranch: 946$a|975$a In this case, we are using the fallback behavior. VendorA stores the branch data in 946, and VendorB stores it in 975. This seems like it would work, but it won't! That's because Koha is expecting there to be the same number of 946's as there are 975's! In reality, the VendorA records will have a number of 946's, and *zero* 975's. The inverse will be true for VendorB. Koha should be able to skip those tags that simply don't exist in the record. Test Plan: 1) Set MarcItemFieldsToOrder to something like: homebranch: 946$a|975$a holdingbranch: 946$a|975$a budget_code: 946$f|975$f itype: 946$y|975$y notforloan: 946$l|975$l ccode: 946$t|975$c quantity: 946$q|975$q price: 946$p|975$p itemcallnumber: 946$n|975$n loc: 946$c|975$t 2) Create a record using only the 975 tag for item building data 3) Import the record into Koha 4) Create a basket 5) Attempt to add the record to the basket 6) Note the unequal fields error 7) Apply this patch 8) Reload the page 9) No error! Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marci Chen <mchen@mckinneytexas.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Amended: Fix typo occurrance and theses. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Pushed to master for 18.05, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19813 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #7 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- Pushed to 17.05.x for v17.05.08 -- You are receiving this mail because: You are watching all bug changes.