November 2014 - Koha-bugs - lists.koha-community.org

[Bug 13310] New: Search.pl needs to show holds total
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13310 Bug ID: 13310 Summary: Search.pl needs to show holds total Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be preferable to see the total number of holds on the staff search results page (search.pl) as the patrons do (but with the correct total). Christopher -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11907] New: Status in search.pl doesn't match status in detail.pl
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11907 Bug ID: 11907 Summary: Status in search.pl doesn't match status in detail.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org The search.pl page only shows the name of the category for a status, such as DAMAGED or LOST, rather than the specific status used from those categories. You see the true status of these items in the detail.pl page, but it would be preferable to see the same status EVERYWHERE, or at least have the option to see it the same everywhere. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 7398] New: Show number of holds on a biblio in the OPAC details
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7398 Bug #: 7398 Summary: Show number of holds on a biblio in the OPAC details Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com Like on the staff client, it should be possible to show the number of holds currently on a title. This will allow patrons to know how long a wait is going to be without having to log into the OPAC. Work to be done: * Add a new system preference, OPACShowHoldsCount, that will control whether the total number of holds shown on the OPAC detail page or not. Summon this syspref on the opac-detail page, and pass to the template * Add call to GetReservesfrombiblionumber. Take the holdcount return variable, and pass it to the template. * Edit opac-detail.tt to check for OPACShowHoldsCount, and if it's true, display the number of holds in a div similar to the one used staff-side * Edit the opac.css to properly and aesthetically display this new div -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 49

[Bug 9342] New: zebra UNIMARC dom indexing does not work
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9342 Bug ID: 9342 Summary: zebra UNIMARC dom indexing does not work Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: paul.poulain(a)biblibre.com CC: m.de.rooy(a)rijksmuseum.nl Testing bug 8984, I find that the UNIMARC dom indexing does not work. Without patch 8984, a fresh install, with UNIMARC, DOM and CHR (not ICU) result in a bad: 15:28:48-03/01 zebraidx(25369) [warn] Unknown register type: (and no indexing is made) -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 3766] Cities/Towns and Road Types only on one address
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3766 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25568|0 |1 is obsolete| | -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 3766] Cities/Towns and Road Types only on one address
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3766 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|oleonard(a)myacpl.org |koha-bugs(a)lists.koha-commun | |ity.org -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13306] New: Problems when cloning subfields with cataloguing plugins
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13306 Bug ID: 13306 Summary: Problems when cloning subfields with cataloguing plugins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The following problem is quite exceptional but worth mentioning: If you clone a subfield with a plugin, the plugin of the clone [often..]operates on the value of the first subfield. This has a few causes: 1) Instead of using the id parameter of the javascript function, the code in the plugin uses a perl variable in the javascript code. The cloned id is passed to onclick but ignored. 2) The Blur, Focus and Change event attributes are not even modified when cloning a subfield. Both things are true in e.g. marc21_leader.pl. If you connect this plugin to say 040d and you clone the field, you will see that clicking the second plugin operates on the first value. If you clear both fields, the Focus of the second field will fill the first field. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 13281] New: t/ImportBatch.t shouldn't depend on the DB
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13281 Bug ID: 13281 Summary: t/ImportBatch.t shouldn't depend on the DB Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: magnus(a)enger.priv.no QA Contact: gmcharlt(a)gmail.com Blocks: 13275 With MySQL turned off: $ sudo -u kohadev-koha KOHA_CONF=/etc/koha/sites/kohadev/koha-conf.xml prove t/ImportBatch.t t/ImportBatch.t .. DBI connect('dbname=koha_kohadev;host=localhost;port=3306','koha_kohadev',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at C4/Context.pm line 785 t/ImportBatch.t .. 1/1 # Failed test 'use C4::ImportBatch;' # at t/ImportBatch.t line 12. # Tried to use 'C4::ImportBatch'. # Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at C4/Context.pm line 785. # Compilation failed in require at C4/Search.pm line 28. # BEGIN failed--compilation aborted at C4/Search.pm line 28. # Compilation failed in require at C4/AuthoritiesMarc.pm line 24. # BEGIN failed--compilation aborted at C4/AuthoritiesMarc.pm line 24. # Compilation failed in require at C4/ImportBatch.pm line 28. # BEGIN failed--compilation aborted at C4/ImportBatch.pm line 28. # Compilation failed in require at t/ImportBatch.t line 12. # BEGIN failed--compilation aborted at t/ImportBatch.t line 12. # Looks like you failed 1 test of 1. t/ImportBatch.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Test Summary Report ------------------- t/ImportBatch.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 3 wallclock secs ( 0.02 usr 0.01 sys + 0.58 cusr 0.65 csys = 1.26 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 13199] New: Incoherence between 'en' sample notices and translated notices
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13199 Bug ID: 13199 Summary: Incoherence between 'en' sample notices and translated notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: frederic(a)tamil.fr QA Contact: gmcharlt(a)gmail.com Koha sample notices are loaded to 'letter' table from a text SQL file during Koha installation by web installer. The reference file is the one provided for English (en) installation : <koha_root>/installer/data/mysql/en/mandatory/sample_notices.sql Alternatives files are provided for other languages. Those files are difficult to keep synchronized with reference file. This could be an functional issue since some Koha operation depend on notice existence, for example Print Slip in Circulation. For example, for French installation, those notices are missing: ISSUEQSLIP, ISSUESLIP, OPAC_REG_VERIFY, RESERVESLIP, TRANSFERSLIP -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 7878] New: When duplicating a patron too many fields carrying over
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '14

20 Nov '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7878 Priority: P5 - low Change sponsored?: --- Bug ID: 7878 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: When duplicating a patron too many fields carrying over QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha When duplicating the patron in the top section only the Surname should carry over - right now the other name and initials carry over. Along the same lines at the bottom the expiration date is coming over and that could be different based on when you're doing the duplication and your patron category rules. -- You are receiving this mail because: You are watching all bug changes.

1 12