Bug 17156 - Record matching on tag 001 does not work
Summary: Record matching on tag 001 does not work
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 16.05
Hardware: All All
: P5 - low minor (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-22 12:44 UTC by joachim.ganseman
Modified: 2017-06-14 22:10 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Screenshot of matching rule (15.57 KB, image/png)
2016-08-22 13:18 UTC, joachim.ganseman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description joachim.ganseman 2016-08-22 12:44:06 UTC
Reproduction of the problem:
- Stage and import a MARC21 record that contains data in Field 001. Update the zebra-index if necessary.
- Define a record matching rule (in Administration -> Record Matching Rules) on Field 001: Search index = Control-number ; Tag = 001 ; leave Subfield, Offset and Length empty.
- Now import the exact same record again, using this matching rule.

Expected result: match found
Actual result: no match found

My gut feeling is that because 001 is a Control Field without any subfields, something goes wrong.
Comment 1 Katrin Fischer 2016-08-22 12:48:51 UTC
Which version did you test this in? How does your 001 field look like?

We use matching on Control-number in almost all our installations up to 3.22.x - so I hope it's a configuration issue and not a bug (and if it's a bug, we should fix this really fast)

Can you share a screenshot of your matching-rule set-up?
Comment 2 joachim.ganseman 2016-08-22 13:18:36 UTC
Created attachment 54690 [details]
Screenshot of matching rule
Comment 3 joachim.ganseman 2016-08-22 13:30:25 UTC
I sincerely hope too that it's a config mishap :) A screenshot was just attached. I'm using Koha 16.05 on Ubuntu Trusty (14.04) with all of the latest package updates installed.

Actually what happens is that there is no match detected on 001, so a new bibliographic record gets made, however the accompanying 952 item does get detected as a duplicate barcode (match on 952$p), so the item is not added. Net result: 2 biblios with only 1 having an item attached.

Our field 001 is populated with the internal shelfmark. This can be any text string, including spaces, punctuation, and alphanumeric characters including capital letters. But I'm currently testing with a file that contains only simple 5-digit numbers in that field, and there I can't get it to match either.
Comment 4 joachim.ganseman 2016-08-22 14:37:19 UTC
Yikes, it was my fault after all - turns out my index still wasn't updated - maybe I tried to be too fast. Or there's some caching issue on my system. In any case, the exact same configuration now works flawlessly for me.

I did notice that zebra couldn't get to the correct /var/lock directory after my last reset of the DB though, but after a sudo chown on that directory to the koha user on my system, that seemed to work.

I'll delete this bugreport then. Terribly sorry for the scare :)
Comment 5 Katrin Fischer 2016-08-22 17:16:00 UTC
All good :) Still a bit glad it's not a bug!