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.
Created attachment 69804 [details] [review] 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!
Created attachment 69830 [details] [review] 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>
Created attachment 70110 [details] [review] 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.
"MarcItemFieldsToOrder cannot handle a tag not existing": This commit message does not describe what the patch does
Pushed to master for 18.05, thanks to everybody involved!
Awesome work all, pushed to stable for 17.11.02
Pushed to 17.05.x for v17.05.08