July 2011 - Koha-bugs - lists.koha-community.org

[Bug 6020] New: Reworking C4::Biblio for performance improvements
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '11

29 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6020 Bug #: 6020 Summary: Reworking C4::Biblio for performance improvements Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5999 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 11

[Bug 5667] New: koha-conf.xml missing entry for z39.50 publicserver
by bugzilla-daemon＠bugs.koha-community.org 28 Dec '11

28 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5667 Summary: koha-conf.xml missing entry for z39.50 publicserver Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 By default, the koha-conf.xml created by make does not include a set of configurations for a public Z39.50 server. There is a line to uncomment to activate public Z39.50 search, but the BIBLIOGRAPHIC RECORDS <server> tag must be copied and given a new id of 'publicserver' in order for one to be able to search the catalog. This configuration tag should be included in the default, commented out just like the line to turn on publicserver listening. A comment should be included with simple instructions. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 11

[Bug 5565] New: Default OAI UNIMARC to Dublin Core XSL adds superfluous blanks
by bugzilla-daemon＠bugs.koha-community.org 28 Dec '11

28 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5565 Summary: Default OAI UNIMARC to Dublin Core XSL adds superfluous blanks Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 DC <dc:creator> contains blanks between forename and surname. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 22

[Bug 4955] New: adding to basket with no item throws error
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '11

27 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4955 Summary: adding to basket with no item throws error Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/acqui/addorder.pl OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When I am adding items to the basket and ignore the 'add item' form (filling in no values) I get the following error when I click 'save' -------------- Software error: :7: parser error : Opening and ending tag mismatch: record line 6 and datafield </datafield> ^ :8: parser error : Opening and ending tag mismatch: collection line 2 and record </record> ^ :9: parser error : Extra content at the end of the document </collection> ^ at /usr/lib/perl5/XML/LibXML/SAX/Parser.pm line 31 For help, please send mail to the webmaster (staff(a)bywatersolutions.com) giving this error message and the time and date of the error. -------------- The item is added to my basket despite this error though. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 7

[Bug 6198] New: Use 001 (not biblionumber) as record identifier for OAI-PMH
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '11

27 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6198 Bug #: 6198 Summary: Use 001 (not biblionumber) as record identifier for OAI-PMH Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org With the OAI-PMH:archiveID syspref it is possible to decide what the first part of Koha's OAI-PMH identifiers should look like. The last part, however, is always the biblionumber of the record. In some settings this might work just fine, but in other settings there might be an identifier in MARC field 001 (at least for MARC21 and NORMARC, not sure about UNIMARC) that would make more sense as an identifier for OAI-PMH records. Two possibilities: - Create a syspref that lets a library choose whether to use biblionumber or 001 as identifier for OAI-PMH (this would make it possible to have something specific in 001, but still use biblionumbers for OAI-PMH if the library so wishes) - Change Koha to always use 001 as the (last part of the) identifier for OAI-PMH. (This way, if alibrary needs to have something specific in 001 they can, but that will also automatically be used for the OAI-PMH identifier. There should be an easy way to make sure 001 is always equal to the biblionumber for libraries that do not need to use 001 for something specific). Thoughts? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 3

[Bug 5897] New: Hide name of reviewer / comment writer in OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '11

13 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5897 Bug #: 5897 Summary: Hide name of reviewer / comment writer in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC Comments AssignedTo: gmcharlt(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org It should be possible to hide/not show the name of the patron who wrote a comment in the OPAC. (privacy) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 17

[Bug 4813] New: implement XSLTResultsDisplay
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '11

08 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4813 Summary: implement XSLTResultsDisplay Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 This system preference exists but is not functional yet. To complete this feature, stylesheets need to be written for format bibliographic records in the staff interface search results display. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 1

[Bug 6278] New: Funny translation bug with XSLT subfieldSelect parameters
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '11

07 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6278 Bug #: 6278 Summary: Funny translation bug with XSLT subfieldSelect parameters Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org English XSLT contains constructs as: <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">at</xsl:with-param> </xsl:call-template> The translated Dutch XSLT contains: <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">bij</xsl:with-param> </xsl:call-template> Since at is not a word here, but just two subfields a and t, they should not have been translated of course. Incidentally, bij is the Dutch translation of the English at. The word gets translated and so subfields a and t are replaced by b, i and j. In most cases resulting in no information. Note: Occurs 5 times in MARC21slim2OPACDetail.xsl. And affects display of fields 490/8XX, 773, 780/785. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 16

[Bug 5780] New: RIS format export not exporting URI field
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '11

07 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5780 Bug #: 5780 Summary: RIS format export not exporting URI field Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org When exporting a record as RIS, the 856u field is being ignored -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 14

[Bug 6584] New: Enable searching on Zebra's Bib-level index
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '11

07 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6584 Bug #: 6584 Summary: Enable searching on Zebra's Bib-level index Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org Bib-level is already indexed in MARC21 record.abs. But you cannot search this index, because it is commented in ccl.properties and not listed in getIndexes of Search.pm. This very simple patch does only do those two things. Before testing it, search in the OPAC for Bib-level=m. Do you get an error? Test this patch now by applying the patch, copy ccl.properties to your zebra config folder (in etc/zebradb folder) and reindex! After that search for Bib-level=m. Probably, you will have many hits. But you should not get an error. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 8