[Koha-bugs] [Bug 33277] Correctly handle linking subfields with no defined thesaurus

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Mar 24 00:30:22 CET 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33277

--- Comment #31 from Janusz Kaczmarek <januszop at gmail.com> ---
(In reply to Nick Clemens from comment #26)
> (In reply to Janusz Kaczmarek from comment #25)
> > Nick, I have looked into the corrected version. I see one problem: with
> > Zebra, for:
> > 
> > 655 7 $a Literatura angielska $2 DBN
> > 
> > you search first for: "Literatura angielska + DBN" and, since there is no
> > 040 $f, there is the second query for: "Literatura angielska + undefined'
> 
> The second query passes "notdefined" - not undef 
[...]

Nick, thank you very much for you comment.  My eyes misses the difference
between 'notdefined' for 'z' without 040 $f and 'notspecified' for '|'.  I am
sorry for unnecessarily bothering you.


I understand your explanation about hardcoding Subject-heading-thesaurus but,
to be sincere, I do not share this argument.  Firstly, in Zebra also we have
the definitions in the configuration file--if somebody changes there something
he/she shouldn't, its his/her fault.  And secondly, which is IMHO more
important, shall we than, in the next step, hardcode also
Heading-use-main-or-added-entry for 008/14, Heading-use-series-added-entry for
008/16, Heading-use-subject-added-entry for 008/15 when we will be wanting to
narrow the search for linking even more specifically (which should definitely
be done at some point)?  So, I am still not convinced if it is the right
idea...

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list