Summary: | Broken title link in UNIMARC catalog search results table | ||
---|---|---|---|
Product: | Koha | Reporter: | Oleg Vasylenko <synapse.ova> |
Component: | Staff interface | Assignee: | Oleg Vasylenko <synapse.ova> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | dubyk, fridolin.somers, gmcharlt, gveranis, jonathan.druart, julian.maurice, katrin.fischer, paul.poulain |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17730 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Bug 18369: Broken title link in UNIMARC catalog search results table |
Description
Oleg Vasylenko
2017-04-03 10:11:27 UTC
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 *** |