Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing
Summary: MarcItemFieldsToOrder cannot handle a tag not existing
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Kyle M Hall
QA Contact: Marcel de Rooy
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-14 15:30 UTC by Kyle M Hall
Modified: 2018-06-04 20:15 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing (3.41 KB, patch)
2017-12-14 15:34 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing (3.51 KB, patch)
2017-12-15 19:12 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 19813 - MarcItemFieldsToOrder cannot handle a tag not existing (4.03 KB, patch)
2017-12-22 10:03 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2017-12-14 15:30:52 UTC
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.
Comment 1 Kyle M Hall 2017-12-14 15:34:01 UTC
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!
Comment 2 Kyle M Hall 2017-12-15 19:12:08 UTC
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>
Comment 3 Marcel de Rooy 2017-12-22 10:03:35 UTC
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.
Comment 4 Jonathan Druart 2017-12-22 16:09:33 UTC
"MarcItemFieldsToOrder cannot handle a tag not existing": This commit message does not describe what the patch does
Comment 5 Jonathan Druart 2017-12-22 16:17:30 UTC
Pushed to master for 18.05, thanks to everybody involved!
Comment 6 Nick Clemens 2018-01-15 16:44:24 UTC
Awesome work all, pushed to stable for 17.11.02
Comment 7 Fridolin SOMERS 2018-01-19 12:33:07 UTC
Pushed to 17.05.x for v17.05.08