Bug 18369 - Broken title link in UNIMARC catalog search results table
Summary: Broken title link in UNIMARC catalog search results table
Status: RESOLVED DUPLICATE of bug 22969
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Oleg Vasylenko
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-03 10:11 UTC by Oleg Vasylenko
Modified: 2020-06-12 22:08 UTC (History)
8 users (show)

See Also:
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 (3.42 KB, patch)
2017-04-03 11:33 UTC, Oleg Vasylenko
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Oleg Vasylenko 2017-04-03 10:11:27 UTC
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.
Comment 1 Oleg Vasylenko 2017-04-03 11:33:16 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
Comment 2 Oleg Vasylenko 2017-04-03 11:45:25 UTC
This problem happens in 16.05+
Comment 3 Paul Poulain 2017-04-07 12:10:52 UTC
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
Comment 4 Oleg Vasylenko 2017-04-07 13:12:55 UTC
This bug will reveal itself if record has empty 001, or 001 is not biblionumber
Comment 5 Paul Poulain 2017-04-07 14:01:21 UTC
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 ;-) )
Comment 6 Katrin Fischer 2017-04-11 05:41:05 UTC
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.
Comment 7 Katrin Fischer 2017-10-15 12:04:22 UTC
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.
Comment 8 Paul Poulain 2017-10-16 07:17:06 UTC
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.
Comment 9 Katrin Fischer 2017-10-16 08:55:30 UTC
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.
Comment 10 George Veranis 2020-06-12 22:08:10 UTC

*** This bug has been marked as a duplicate of bug 22969 ***