Bug ID: 19575
Summary: Use canonical field names and resolve aliased fields
Change sponsored?: ---
Priority: P5 - low
Component: Searching - Elasticsearch
Assignee: [hidden email] Reporter: [hidden email]
The current elastic search fields seems to be a mix between zebra aliases,
field names, some duplicates and new fields. This causes issues with sorting in
UI and hard-coded search-links in XSL-templates for example. I have attempted
to clean things up a bit, which resolves many of these issues. I might not have
the time to do so today, but will attempt to find and mark all current issues
resolved by this fix.
--- Comment #3 from David Gustafsson <[hidden email]> ---
Think I have missed a few places (facets for example) where field names are
hard coded and needs to be changes. So no point in trying out patch in it's
current state until these things are fixed.
--- Comment #7 from David Gustafsson <[hidden email]> ---
Think I have been looking at the Zebra-mapping configuration in the wrong place
(this old config, not biblio-koha-indexdefs.xml). I will go through the mapping
changes one more time using this as reference instead.
--- Comment #10 from David Gustafsson <[hidden email]> ---
Wrote a script to extract mappings from biblio-koha-indexdefs.xml and convert
to mappings.yaml, left the fields with existing mapping-targets as they are
(even though discovered several discrepancies with the Zebra mappings) and
mostly just added the missing fields. Will now do more thorough local testing
so will probably adjust this patch some more before ready to be reviewed.
--- Comment #13 from David Gustafsson <[hidden email]> ---
Sorry, should have been more clear about that. Yes, this is ready for signoff.
There is still some stuff I left out of this patch, like:
- New mappings for other marc-flavours than marc21 extracted from
- Correction for some existing mappings (I think some offsets are off by one
- New mappings and posssible corrections for authorities
But if this get reviewed and committed I can open new bug-reports for those
once I have time to further polish the extraction-script.
--- Comment #14 from Jonathan Druart <[hidden email]> ---
(In reply to David Gustafsson from comment #13)
> But if this get reviewed and committed I can open new bug-reports for those
> once I have time to further polish the extraction-script.
--- Comment #15 from David Gustafsson <[hidden email]> ---
Yes, I was thinking to do so, though it is only a quick and dirty script in
Ruby (should perhaps be re-written in perl if to be included in Koha-repo), and
though would clean it up just a little bit more, remove some hard-coded stuff,
add some simple command line options etc. But will post a link to git-repo with
said script once removed the worst ugliness.
--- Comment #24 from David Gustafsson <[hidden email]> ---
Field name 'Date/time-last-modified' does not work with elastic since "/" will
create subfields, koha will also not tokanize this correctly, changed this
(back) to 'Date-time-last-modified'.
--- Comment #27 from Jonathan Druart <[hidden email]> ---
(In reply to David Gustafsson from comment #26)
> Yes should be ready for sign off, have discovered no more issues since the
> most recent patch.
The good way to tell other people that your patch is ready to be tested is to
change the status of the bug report from "Patch doesn't apply" to "Needs