March 2015 - Koha-bugs - lists.koha-community.org

[Bug 13671] New: Search returning empty
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '15

28 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13671 Bug ID: 13671 Summary: Search returning empty Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: isabelaterra(a)cp2.g12.br QA Contact: testopia(a)bugs.koha-community.org After migration from 3.14 to 3.18 koha even with the database fed the search always returns empty. I noticed that the installation of the pt-BR language is in conflict with the Zebra. The zebra indicates en-US and Koha indicates pt-BR. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 10347] New: Deactivate "Add item" button when "Add multiple copies" was activated
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10347 Bug ID: 10347 Summary: Deactivate "Add item" button when "Add multiple copies" was activated Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de It happens often that when trying to add multiple items after entering the number the form is accidentally submitted with "Add item". This way you have to start all over to add your multiple copies as it's not possible to duplicate existing items. I think it would be nice, if the "add item" button could be deactivated on entering a number of copies into the field for multiple items. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 10120] New: Fine recalculation on return needs to be a system preference
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10120 Bug ID: 10120 Summary: Fine recalculation on return needs to be a system preference Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: chris(a)bigballofwax.co.nz, gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As agreed on IRC today, recalculation of fines on return needs to be tied to a system preference as it changes the fines workflow. Ideally the system preference would have 3 settings: - recalculate always - recalculate only for hourly loans - don't recalculate -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 12488] New: bulkmarcimport.pl -d option should use DELETE instead of TRUNCATE
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12488 Bug ID: 12488 Summary: bulkmarcimport.pl -d option should use DELETE instead of TRUNCATE Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org bulkmarcimport.pl -d ("Delete EVERYTHING related to biblio in koha-DB before import. Tables: biblio, biblioitems, items") use this code if ($delete) { if ($biblios){ print "deleting biblios\n"; $dbh->do("truncate biblio"); $dbh->do("truncate biblioitems"); $dbh->do("truncate items"); } else { print "deleting authorities\n"; $dbh->do("truncate auth_header"); } $dbh->do("truncate zebraqueue"); } But, as Robin Sheat[1] point me this is a deprecated way. Now, with MySQL >~5.5 the way is just to: DELETE FROM biblio; And the constraints will propagate the delete to (ALMOST) all other tables. [1] http://lists.katipo.co.nz/public/koha/2014-June/039701.html Related bug: #12486. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 13379] New: authorised_values.category is varchar(16)
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13379 Bug ID: 13379 Summary: authorised_values.category is varchar(16) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org But borrower_attribute_types is varchar(10). So if you try to link a patron attribute type with an AV category with a length > 10, the link won't be done. Also, I propose to extend this field to varchar(32). -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 12486] New: Appendix G (Resetting the Koha Database) using DELETE instead of TRUNCATE
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12486 Bug ID: 12486 Summary: Appendix G (Resetting the Koha Database) using DELETE instead of TRUNCATE Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: nengard(a)gmail.com Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Manual appendix G, "Resetting the Koha Database"[1] talks about resetting Koha database with TRUNCATE SQL command. As Robin Sheat[2] point me this is a deprecated way. Now, with MySQL >~5.5 the way is just: DELETE FROM biblio; And the constraints will propagate the delete to (ALMOST) all other tables. [1] http://manual.koha-community.org/3.16/en/resetkohadb.html [2] http://lists.katipo.co.nz/public/koha/2014-June/039701.html I'll fill another bug about updating also bulkmarcimport.pl -d option. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 12598] New: Allow tools/import_borrowers.pl to be used from the command line.
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12598 Bug ID: 12598 Summary: Allow tools/import_borrowers.pl to be used from the command line. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many libraries have the need to automate the importing of patrons into Koha from external sources. It would be nice if we could use Koha's own import_borrowers.pl to do that from the command line, in the same way as tools/export.pl can be used from both the staff interface and the command line. -- You are receiving this mail because: You are watching all bug changes.

1 72

[Bug 13696] New: Add support for Font Awesome icons in Koha
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13696 Bug ID: 13696 Summary: Add support for Font Awesome icons in Koha Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Font Awesome is similar to Glyphicons included in Twitter Bootstrap, except better in every way and more Free. -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 10454] New: Failure to lock could generate duplicate card numbers
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10454 Bug ID: 10454 Summary: Failure to lock could generate duplicate card numbers Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In C4::Members.pm there is a function AddMembers_Opac which calls fixup_cardnumber. The problem is there is no locking to ensure that someone else doesn't add a member at the same time and create a duplicate card number. This patch adds the missing locking in. I've left commented wait code in, so that the person testing this can switch tabs or browsers to test that the locking doesn't catastrophically break things. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 11780] New: Need to prevent specific fields from being overwritten with z39.50 import
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '15

27 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11780 Bug ID: 11780 Summary: Need to prevent specific fields from being overwritten with z39.50 import Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: Jeremy.evans(a)nibsc.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In our previous LMS we could associate specific marc fields as "local use" in the configuration. If a marc record was overwritten with another via z39.50 these local use files remained in the new record. (if it was in a field that also contained data in the incoming record, then a 2nd instance for that field was created - e.g. multiple 500 notes, etc e.g. we need to keep our own 001 control numbers as Analytics links from other records get broken if this is replaced with the 001 of a new record say from LC or NLM. At the moment I have to note the existing 001 & put that value in again after replacing the record. There are also local notes fields etc that we would want to keep. It would be useful if this setting is also framework specific. (e.g. to keep certain fields for serials but not for monographs etc) -- You are receiving this mail because: You are watching all bug changes.

1 3