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

[Bug 12766] New: Display MARC 245 subfields in exact order as on MARC cataloging/edit screen
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '14

24 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12766 Bug ID: 12766 Summary: Display MARC 245 subfields in exact order as on MARC cataloging/edit screen Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: imingchan(a)yahoo.com.au QA Contact: testopia(a)bugs.koha-community.org Created attachment 30830 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30830&action=edit Screen image In "Normal" view, details from MARC 245 (Title) are not showing in the exact subfield order as on the MARC cataloging/edit screen, in particular: $n (part number) and $p (part name). It should be: $a, $n, $p, $h, $b, $c See attached screen image. The title should read as: Mining railways of Cobar. 7. Other mines, 1871-1922 [journal citation] / instead of: Mining railways of Cobar. [journal citation] / 7. Other mines, 1871-1922 -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9963] New: Inventory tool doing strange things
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '14

24 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9963 Bug ID: 9963 Summary: Inventory tool doing strange things Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com I can't come up with a better title that I have. You have to see this to understand what's going on: http://www.screencast.com/t/62evHO7OuST When I submit my criteria the first time, it comes up as expected. But after clicking Mark seen, it comes up with items that do not meet my original criteria. This is a problem in 3.10.3 and master. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12720] New: Turn off Authority logging when running "bulkmarcimport.pl"
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '14

24 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12720 Bug ID: 12720 Summary: Turn off Authority logging when running "bulkmarcimport.pl" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, there is no provision to disable logging when running "bulkmarcimport.pl" in authority mode. There is for bibliographic mode, and it seems to presumably be for performance reasons. (I would think both in terms of the import and in terms of querying the action_logs table, as that could get quite cumbersome if you import 600,000 authorities.) -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 12744] New: Set language in staff client should have 'Cancel' link
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '14

24 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12744 Bug ID: 12744 Summary: Set language in staff client should have 'Cancel' link Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 12423] New: librarything reviews aren't showing in bootstrap
by bugzilla-daemon＠bugs.koha-community.org 24 Aug '14

24 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12423 Bug ID: 12423 Summary: librarything reviews aren't showing in bootstrap Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 28847 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28847&action=edit no content showing See attached. There is nothing next to the label for reviews from librarything. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 12796] New: Default Messaging Preferences not Applied
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '14

23 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12796 Bug ID: 12796 Summary: Default Messaging Preferences not Applied Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dminuck(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a patron registers through the OPAC, the default messaging preferences for their category are not applied. Additionally, when changing a patron's category in the staff client (or when leaving the messaging preferences fields blank) the defaults are not applied, even though the template indicates that they will be. 9556 addressed the second part and was reported as fixed and pushed to 3.10, but in 3.16 the bug persists. We're on a customized version of 3.16, but have verified the bug on ByWaters demo which is on 3.17, and I assume 'stock'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8838] New: Digest option for HOLD FILLED notice?
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '14

23 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8838 Priority: P5 - low Change sponsored?: --- Bug ID: 8838 Assignee: koha-bugs(a)lists.koha-community.org Summary: Digest option for HOLD FILLED notice? Severity: enhancement Classification: Unclassified OS: All Reporter: mcoalwell(a)nekls.org Hardware: All Status: NEW Version: rel_3_6 Component: Notices Product: Koha Is there a way to set Koha to only send one email to a patron when they have several items on hold instead of one email for each item? We've had a couple of patrons ask and 12 emails put a patron over her email inbox quota. Thanks, Erica Voell Bonner Springs City Library -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 12809] New: Failures in Koha notifications systems
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '14

22 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12809 Bug ID: 12809 Summary: Failures in Koha notifications systems Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: fred.pierre(a)smfpl.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 31105 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=31105&action=edit There are too many unrealistic letter and delay combinations. The Koha notifications system has four main components: 1. A message_transport_type for each notification method 2. A letter or "notice" for each of the message_transports 3. A "delay" and "letter" selection process for overdue actions. 4. The option of "EnhancedMessagingPreferences" allowing patrons and staff to define specific patron notifications. In the staff interface, we refer to defined letters both as "notices" and sometimes as "letters." Overdue notices get a separate interface, allowing three letters to be selected to send. Creating a single framework for pre-due and overdue notifications would simplify the process of configuring specific patron settings. Goals for improvement should include: 1. Define a more consistent notifications failover chain - either user-defined or pre-set to "SMS > Email > Phone > Print Notice." Consider points #4 and #5 below - how is this affected when we add a new message_transport_type, or if we combine all notifications into one framework? A numeric priority should be set for the message_transport_type, and should failover in that order. Adding a new message_transport_type would force re-sequencing of those priorities. 2. Combine SMS number (Patron Messaging Preferences) with patron's mobile phone number. I can't imagine these would ever be different in practice. Instead of requiring a separate "SMS number" to be defined, we should simply use the patron messaging preference's SMS checkbox to select SMS messaging to the mobile number. At the very least the mobile number should populate the SMS field, because there is no way to define the SMS number through the New Patron memberentry.pl script. 3. Allow "Days in Advance" to function for Advance notices, by enabling user to activate the "takes_days" flag in the message_attributes table. 4. The "letter" selection process in overduerules.pl is extremely flawed. For example, you can set a delay on an advance notice, but it in practice, this doesn't function the way you would logically expect. We need to combine pre-due and overdue notifications, perhaps by using a "negative" days in advance value, or a "days before" and "days after" pull-down. Combining pre-due and overdue notices will reduce confusion both in the user interface and in the batch processing of notifications. We already define all notices or "letters" through a single letter.pl script. We should also implement one process to send out both pre-due and overdue notifications, and one interface to specify every outgoing message, with a goal of simplicity and de-duplication of function. 5. Allow new notification methods to be defined in the message_transport_type table. For example, we should be able to tag specific patrons for automated phone calling through I-Tiva with a user-defined "Itiva" message_transport_type. Thank for considering these idea! I may be missing different use cases, but I can see clear advantages to streamlining and combining the notifications processes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 12545] New: Add EditorConfig file to the source tree
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '14

22 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12545 Bug ID: 12545 Summary: Add EditorConfig file to the source tree Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It'd be usefull to have a .editorconfig [1] file, that enforces some of our coding guidelines, in the source tree top level. Those developers that have their editors configured to honour the file, will benefit. Those that wouldn't use it, won't get bothered by the addition. So, a harmless addition that would benefit those that are interested. There are plugins for several major editors: - Emacs - Vim - SublimeText - and so on... [1] http://editorconfig.org/ -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 12776] New: Capitalization: confirmation messages in circulation
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '14

22 Aug '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12776 Bug ID: 12776 Summary: Capitalization: confirmation messages in circulation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Some of the confirmation messages when checking out or renewing items are not following the capitalization rules. -- You are receiving this mail because: You are watching all bug changes.

1 9