In staff client, «Search the catalog» returns a table, where biblio title has a broken link (biblionumber is absent), yet other links works good (Holds, Edit Record, Edit items, OPAC view) Steps to Reproduce: In staff client, search the catalog (Cataloging → «Search the catalog» (/cgi-bin/koha/catalogue/search.pl)) Actual Results: Title of the biblio has a link, that doesn't have biblionumber Expected Results: Title of the biblio should have a link with a proper biblionumber at the end Additional Information: Each biblio in the results table is shown by XSL transformation of MARC data. XSL (\intranet-tmpl\prog\en\xslt\UNIMARCslim2intranetResults.xsl) prepares a link, and adds a biblionumber, that it expects to get from controlfield 001. But since this field could be either empty or contain something different than biblionumber (see https://lists.katipo.co.nz/public/koha/2015-September/043652.html), it is better to pass the biblionumber to this script. This script is already receiving sysprefs (that is not according to marcxml standart), so I suggest to pass the biblionumber the same way.
Created attachment 61793 [details] [review] Bug 18369: Broken title link in UNIMARC catalog search results table Patch adds biblionumber to XSLT the same way Sysprefs are added, in the C4/XSLT.pm
This problem happens in 16.05+
I tried to reproduce this error, and couldn't. I'm running UNIMARC, default XSLT, and the links are working fine (master branch) There's probably another specific parameter to see the bug
This bug will reveal itself if record has empty 001, or 001 is not biblionumber
In my setup, the biblionumber is in 001, this explain that (can't sign-off this patch, but OTOH, won't failed QA it either ;-) )
I think in the french UNIMARC installer everything is set up for 001 = biblionumber. I am not sure if having the bilbionumber stored elseqhere in a UNIMARC setup won't cause you more trouble overall.
I still think that changing the default mapping of the biblionumber is quite dangerous. You'd also have to adjust your indexing and possibly see problems in some other spots. Setting this to 'In Discussion', and cc'ing some UNIMARC experts.
Katrin, it's not changing the default mapping, it's just removing a hardcoding of biblionumber in 001 in XSLT Instead of building the biblionumber from hardcoded 001 field, this patch send $biblionumber to the XSL, and uses it where needed : Send the biblionumber as parameter: + my $kohavars = "<koha>\n<biblionumber>$biblionumber</biblionumber>\n</koha>\n"; Instead of 001, us the $biblionumber: - <xsl:variable name="biblionumber" select="marc:controlfield[@tag=001]"/> + <xsl:variable name="biblionumber" select="marc:koha/marc:biblionumber"/> PS: not sure the patch is perfect, complete or valid. But I 100% agree with the fact that we must not assume that biblionumber is in 001.
I know, but should we encourage changing the UNIMARC default mapping, when the index for biblionumber etc will be wrong if you do that? If we are not supporting the use case, we should not start adding code to work around it.
*** This bug has been marked as a duplicate of bug 22969 ***