ff7-00 is set to: 007_/1 it should be mapped to position 0 I believe any other specific character positions should be checked to ensure they are corect as well To recreate: 1 - Find an item with an 007 in your catalog 2 - Make sure it is indexed in ES 3 - View the ES record: kohadevbox curl 'localhost:9200/koha_kohadev_biblios/data/19?pretty=yes' | grep -A7 ff7 koha testing docker curl 'es:9200/koha_kohadev_biblios/data/19?pretty=yes' | grep -A7 ff7 adjust for other setups 4 - Note the 00 indexes the 01 position, etc
*** Bug 22256 has been marked as a duplicate of this bug. ***
Created attachment 86597 [details] [review] Bug 22339: Fix search field mappings of MARC fixed fields Fixes handling of /0 selector in addition to several fixed field positions. Note that ff7-01-02 is in fact 00-01 in Zebra and that has been replicated here. Test plan: 1. Before applying a patch, check from Elasticsearch (e.g. localhost:9200/koha_biblios/_search?q=_id:123) what is indexed in Elasticsearch for a record for date-entered-on-file, ff7-00, ff7-01, ff7-02 and lleader. 2. Apply the patch, update database and save the record again. 3. Verify that the contents of the forementioned fields is now correct in Elasticsearch. 4. Verify that tests pass: prove -v t/Koha/SearchEngine/Elasticsearch.t
Note that it seems ff7-01-02 was misnamed in Zebra, and that is reflected here. It contains positions 00-01.
Note that leader-fields should be spelled "LDR".
Frank, sorry, I'm not following. Can you explain with a bit more detail?
It is a little bit confusing because according to the MARCXML standard, leader field is called "leader". But I discovered that in ES, leader fields obviously is marked up as "LDR" instead of "leader". I have no idea why. Maybe it's a Koha or a Catmandu thing. The thing is, ES fields that comes from content in the leader will not be indexed unless the mapping is corrected to "LDR".
Created attachment 87905 [details] [review] Bug 22339: Fix search field mappings of MARC fixed fields Fixes handling of /0 selector in addition to several fixed field positions. Note that ff7-01-02 is in fact 00-01 in Zebra and that has been replicated here. Test plan: 1. Before applying a patch, check from Elasticsearch (e.g. localhost:9200/koha_biblios/_search?q=_id:123) what is indexed in Elasticsearch for a record for date-entered-on-file, ff7-00, ff7-01, ff7-02 and lleader. 2. Apply the patch, update database and save the record again. 3. Verify that the contents of the forementioned fields is now correct in Elasticsearch. 4. Verify that tests pass: prove -v t/Koha/SearchEngine/Elasticsearch.t Signed-off-by: Björn Nylén <bjorn.nylen@ub.lu.se>
Yes, it seems to work after all. Leader fields is indexed as it should. Perfekt!
Created attachment 88706 [details] [review] Bug 22339: Fix search field mappings of MARC fixed fields Fixes handling of /0 selector in addition to several fixed field positions. Note that ff7-01-02 is in fact 00-01 in Zebra and that has been replicated here. Test plan: 1. Before applying a patch, check from Elasticsearch (e.g. localhost:9200/koha_biblios/_search?q=_id:123) what is indexed in Elasticsearch for a record for date-entered-on-file, ff7-00, ff7-01, ff7-02 and lleader. 2. Apply the patch, update database and save the record again. 3. Verify that the contents of the forementioned fields is now correct in Elasticsearch. 4. Verify that tests pass: prove -v t/Koha/SearchEngine/Elasticsearch.t Signed-off-by: Björn Nylén <bjorn.nylen@ub.lu.se> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I'll confess to not being a total expert when it comes to MARC fields, but these changes appear to be solid and I can't see any obvious regressions. I really like that we're indexing by '0' now too. Passing QA.
Awesome work all! Pushed to master for 19.05
Pushed to 18.11.x for 18.11.05
not backporting ES bugs/fixes to 18.05.x series