Summary: | fix biblionumber on 001 in UNIMARC XSLT | ||
---|---|---|---|
Product: | Koha | Reporter: | Fridolin Somers <fridolin.somers> |
Component: | MARC Bibliographic data support | Assignee: | Fridolin Somers <fridolin.somers> |
Status: | CLOSED FIXED | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | normal | ||
Priority: | P5 - low | CC: | 1joynelson, arouss1980, hayleypelham, lucas, m.de.rooy, synapse.ova |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
20.05.00, 19.11.05, 19.05.10
|
|
Circulation function: | |||
Attachments: |
Bug 22969: fix biblionumber on 001 in UNIMARC XSLT
Bug 22969: fix biblionumber on 001 in UNIMARC XSLT Bug 22969: fix biblionumber on 001 in UNIMARC XSLT |
Description
Fridolin Somers
2019-05-23 05:54:41 UTC
Created attachment 89994 [details] [review] Bug 22969: fix biblionumber on 001 in UNIMARC XSLT In UNIMARC default configuration the 001 is linked to biblio.biblionumber. In some XSLT files, 090$a is used. This is by default biblioitems.biblionumber so it usually works but it may not be the same and var biblionumber is used to create hyperlinks to record detail page. Test plan : 1) Use UNIMARC database 2) Set default in all XSLT system preferences 3) At OPAC, perform a search and click on a result 4) Check displayed page shows the correct biblio record 5) Same at intranet Hi Fridolin, (In reply to Fridolin SOMERS from comment #0) > In UNIMARC default configuration the 001 is linked to biblio.biblionumber. > In some XSLT files, 090$a is used. > This is by default biblioitems.biblionumber so it usually works but it may > not be the same and var biblionumber is used to create hyperlinks to record > detail page. I think 090$a is linked to biblioitems.biblioitemnumber in UNIMARC default configuration for English (see lines 75-76 of installer/data/mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.sql). While trying to sign off your patch I realised that in my test UNIMARC DB with just four records the values for biblionumber and biblioitemnumber are the same in the SQL tables that I checked: MariaDB [koha_test]> SELECT biblionumber FROM biblio ; +--------------+ | biblionumber | +--------------+ | 1 | | 3 | | 4 | | 5 | +--------------+ MariaDB [koha_test]> SELECT biblionumber, biblioitemnumber FROM biblioitems ; +--------------+------------------+ | biblionumber | biblioitemnumber | +--------------+------------------+ | 1 | 1 | | 3 | 3 | | 4 | 4 | | 5 | 5 | +--------------+------------------+ MariaDB [koha_test]> SELECT biblionumber, biblioitemnumber FROM items ; +--------------+------------------+ | biblionumber | biblioitemnumber | +--------------+------------------+ | 1 | 1 | | 3 | 3 | | 3 | 3 | | 4 | 4 | | 4 | 4 | | 5 | 5 | +--------------+------------------+ When I set all XSLT system preferences to 'default', the hyperlinks in the search results work OK (without the patch applied). So, under what circumstances does this problem occur? How can I create a record that has biblionumber != biblioitemnumber? (In reply to Andreas Roussos from comment #2) > > So, under what circumstances does this problem occur? > How can I create a record that has biblionumber != biblioitemnumber? Hi, indeed it should usually not occur. I think it sometimes appears when some insert in catalog fail to insert in biblio but create a row in biblioitems. In this case autoincrement of biblioitems.biblioitemnumber is higher than biblio.biblionumber. You may try a modification in direct SQL : UPDATE biblioitems SET biblioitemnumber = 6 WHERE biblioitemnumber=5; Only for a test database ! Created attachment 100158 [details] [review] Bug 22969: fix biblionumber on 001 in UNIMARC XSLT In UNIMARC default configuration the 001 is linked to biblio.biblionumber. In some XSLT files, 090$a is used. This is by default biblioitems.biblionumber so it usually works but it may not be the same and var biblionumber is used to create hyperlinks to record detail page. Test plan : 1) Use UNIMARC database 2) Set default in all XSLT system preferences 3) At OPAC, perform a search and click on a result 4) Check displayed page shows the correct biblio record 5) Same at intranet Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Tested on clean UNIMARC install. Before insert new records: "alter table biblioitems AUTO_INCREMENT = 5" Added two records, with result: +--------------+------------------+ | biblionumber | biblioitemnumber | +--------------+------------------+ | 1 | 5 | | 2 | 6 | +--------------+------------------+ Without patch, OPAC results shows for first record http://opac/cgi-bin/koha/opac-detail.pl?biblionumber=5, Wrong! with patch result is correct Works, no errors Created attachment 100213 [details] [review] Bug 22969: fix biblionumber on 001 in UNIMARC XSLT In UNIMARC default configuration the 001 is linked to biblio.biblionumber. In some XSLT files, 090$a is used. This is by default biblioitems.biblionumber so it usually works but it may not be the same and var biblionumber is used to create hyperlinks to record detail page. Test plan : 1) Use UNIMARC database 2) Set default in all XSLT system preferences 3) At OPAC, perform a search and click on a result 4) Check displayed page shows the correct biblio record 5) Same at intranet Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Tested on clean UNIMARC install. Before insert new records: "alter table biblioitems AUTO_INCREMENT = 5" Added two records, with result: +--------------+------------------+ | biblionumber | biblioitemnumber | +--------------+------------------+ | 1 | 5 | | 2 | 6 | +--------------+------------------+ Without patch, OPAC results shows for first record http://opac/cgi-bin/koha/opac-detail.pl?biblionumber=5, Wrong! with patch result is correct Works, no errors Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Nice work everyone! Pushed to master for 20.05 Backported to 19.11.x for 19.11.05 backported to 19.05.x for 19.05.10 Minor/normal patch will not be backported to 18.11.x series *** Bug 18369 has been marked as a duplicate of this bug. *** |