May 2013 - Koha-bugs - lists.koha-community.org

[Bug 9527] New: add all-all-all circulation rule to sample data
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '15

18 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9527 Bug ID: 9527 Summary: add all-all-all circulation rule to sample data Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz You can't do much in circ without a default rule - and we don't have one out of the box. We should add one. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9958] New: RoutingSerials desription misleading
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '15

18 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9958 Bug ID: 9958 Summary: RoutingSerials desription misleading Classification: Unclassified 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 I think in current versions of Koha the RoutingSerials is used to indicate if routing lists are used. Routing related functionality is hidden from screen according to this system preference. The description doesn't reflect that well: Add/Don't add received serials to the routing list. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 9717] New: localuse recorded for holds/transfers
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '15

17 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9717 Bug ID: 9717 Summary: localuse recorded for holds/transfers Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If RecordLocalUseOnReturn is set to "Record" then whenever a hold item is returned from another library, it is being recorded as local use. The library scans the item at check in to cancel the "in transit" status and the item is counted as local use. This seems inaccurate to me. This is going to inflate the local use counts so that libraries think that that many more items are being used in-house when in reality the item is being returned from use at another library in the group. I think that RecordLocalUseOnReturn should only record local use when there is no other status, like holds, transfers, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 8446] New: Shibboleth authentication patch
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '15

16 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8446 Priority: P5 - low Change sponsored?: --- Bug ID: 8446 CC: dpavlin(a)rot13.org Assignee: gmcharlt(a)gmail.com Summary: Shibboleth authentication patch Severity: enhancement Classification: Unclassified OS: All Reporter: francart(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Authentication Product: Koha Created attachment 10841 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10841&action=edit Shibboleth patch for Auth.pm on Koha 3.8 I wrote rudimentary Shibboleth login support for Koha. It's quite specific to our university and Koha setup, but should be easy to modify. I hope someone finds it useful. The attached patch can be applied to lib/C4/Auth.pm of Koha 3.8.2 -- You are receiving this mail because: You are watching all bug changes.

1 179

[Bug 8337] New: System preferences for longoverdue cron
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '15

15 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8337 Priority: P5 - low Change sponsored?: --- Bug ID: 8337 Assignee: gmcharlt(a)gmail.com Summary: System preferences for longoverdue cron Severity: enhancement Classification: Unclassified OS: All Reporter: pelletiermaxime(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Command-line Utilities Product: Koha Patch to follow that adds 3 new system preferences to control the parameters for the longoverdue script. New prefs are DefaultLongOverdueChargeValue, DefaultLongOverdueLostValue and DefaultLongOverdueDays. These preferences are used when you call the longoverdue.pl script without their parameters. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 7556] New: Use "preventDoubleFormSubmit()" more in the OPAC and Intranet to prevent duplicate data
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '15

14 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7556 Bug #: 7556 Summary: Use "preventDoubleFormSubmit()" more in the OPAC and Intranet to prevent duplicate data Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: wizzyrea(a)gmail.com QAContact: koha.sekjal(a)gmail.com Depends on: 6496 When 6496 is pushed, we will have a new jquery function: preventDoubleFormSubmit(). When used thusly: $('#form-id').preventDoubleFormSubmit(); It will prevent a submitted form from being submitted a second (or third, or fourth, or fifth) time. We should probably use this on most submission forms in the OPAC. As Paul states on 6496 - "we can teach librarians not to double click, but not patrons." The function exists in both the OPAC and Intranet, and so it can be used anywhere a double (or rapid) click would resubmit a form. I think we should try to use it more. -- 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 6

[Bug 6832] New: Validation of total > budget in neworderempty
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '15

13 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6832 Bug #: 6832 Summary: Validation of total > budget in neworderempty Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: pelletiermaxime(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5264 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5264 [PATCH] Fix multiple bugs and refactor the code to fix the alert of the total exceeding the budget in neworderempty The javascript function totalExceedsBudget never returns anything. Refactored it to use jQuery for the ajax stuff and to make it work. Only 1 line changed in a tmpl, so should be easy to adapt for 3.4. Steps to reproduce : Create a new order in a basket. Set a total higher than the total of the selected budget. You will see an ajax request, but no error. This patch fixes the return, make it work for ie6 by using jQuery and prints correctly the total of the budget in the 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 23

[Bug 9822] New: No alert appears on adding an order to a basket if the budget has exceeded
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '15

13 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9822 Bug ID: 9822 Summary: No alert appears on adding an order to a basket if the budget has exceeded Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 9810] New: Search limit 'available' does not hide damaged or withdrawn items
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '15

12 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9810 Bug ID: 9810 Summary: Search limit 'available' does not hide damaged or withdrawn items Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 5592] New: circ rule cloning can be dangerous
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5592 Summary: circ rule cloning can be dangerous Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The clone circ rules widget on the circ rules page unconditionally deletes the target library's existing rules and replaces them with copies of the rules from the source library. Consequently, if the clone rule button is accidentally clicked, a lot of configuration work can be destroyed in an instant. To avoid this: * there should *always* be a required confirmation step, whether the clone-rules.pl script is accessed directly or via the smart-rules.pl page * even better, a backup copy of the previous version of the target library's rules could be made The library who ran into this bug had tried cloning the rules form a different library because they thought that would be a way to copy over that library's rules and add them to the rules that the target library had previously entered -- that kind of cloning-via-merge feature also seems like a good idea, in fact. -- 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 4