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

[Bug 13548] New: "High Holds" does not behave correctly when decreaseLoanHighHoldsValue is set to 0.
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '15

18 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13548 Bug ID: 13548 Summary: "High Holds" does not behave correctly when decreaseLoanHighHoldsValue is set to 0. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Partner wants to decrease the length of loans when *any* items are checked out. Setting 'decreaseLoahHighHolds' system preferences as follows: +-------------------------------+------------+ | variable | value | +-------------------------------+------------+ | decreaseLoanHighHolds | 1 [Enable] | | decreaseLoanHighHoldsDuration | 14 | | decreaseLoanHighHoldsValue | 0 | +-------------------------------+------------+ This shows on the system preferences screen as follows: [Enable] the reduction of loan period to [14] days for items with more than [0] holds. Checking out *any* item (regardless of whether or not it has holds) will trigger the following message: High demand item. Loan period shortened to 0 days (due ). Check out anyway? According to the system preferences description, this should not be triggered unless there is at least one hold. According to the partner, if decreaseLoanHighHoldsValue is set to 1, High Holds isn't triggered until an item is checked out that has two holds placed, meaning that it's impossible to trigger at exactly 1 hold placed. when decreaseLoanHighHoldsValue is 0, the loan period is *not* shortened, even though the message pops up. The description of decreaseLoanHighHoldsDuration is also misleading: [Enable] the reduction of loan period to [decreaseLoanHighHoldsDuration] days should read [Enable] the reduction of loan period by [decreaseLoanHighHoldsDuration] days because, the loan period is not set to a constant 'decreaseLoanHighHoldsDuration' days; rather it is decremented by that amount. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 14063] New: Implement language overlay for authorised values
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14063 Bug ID: 14063 Summary: Implement language overlay for authorised values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr There is an urgent need to make authorised values translatable in mulitlingual installations. For the examples I take English (en), French (FR-fr and German (de-DE). Example: OPAC (Public interface) - Set syspref 'suggestion' to: [Allow] patrons to make purchase suggestions on the OPAC. - Select English - OPAC: Log in, go to Purchase suggestions > Create a new suggesion - The dropdown "Reason for suggestion:" shows the authorised values from OPAC_SUG, e.g. "The copy on the shelf is damaged" and "Upcoming title by popular author" - Select German - The dropdown "Begründung" shows the same (English) values. Intranet (Staff client) - Go to Home > Acquisitions > Suggestions management > New purchase suggestion - Switch between languages, the dropdown "Reason for suggestion" changes the label, but the values are not ranslated. - Same with the detail view of a suggestion There are more places with similar problems. The only (poor and ugly looking) possibility is to have multilingual text in the same entry, e.g. "Damaged | Beschädigt | Abîmé" "Upcoming title by popular author | Neuer Titel eines populären Autors |Oeuvre ...." - oh, that gets very long for one line in a drop down... I propose a solution that implements a language overlay for authorised values. It is minimal invasive and can immediately be used in production. Patch follows. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 9026] New: tagging improvements
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9026 Priority: P5 - low Change sponsored?: --- Bug ID: 9026 Assignee: gmcharlt(a)gmail.com Summary: tagging improvements Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Tools Product: Koha I got this email and wanted to share the idea with you all: Right now, tagging works this way: 1) I'm testing tagging, so I tag a title "test" 2) I go into tag moderation and see that, yay, my tag is there waiting, so it works! 3) I can choose to approve the tag test. This means anyone can apply the term test to anything in the catalog now. Not ideal since test can mean a lot of things. Perhaps a student is just using it to mark items they're using to make a test for a project. Not a good use of tags and I won't know that they've done it because I've already approved the tag. Lost my teachable moment. 4) So I reject it, because that's my only option. But now that means I can't use it to test again in the future unless I later go in, then approve it, then use it, then reject it again. I'm just proposing a step that allows you a third option. You have a tag sitting there. You don't want to approve or reject it, you just want to make it go away in this instance. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 5655] New: printing of fines should support more than one line
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5655 Summary: printing of fines should support more than one line Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Today I noticed the new print link next to each account line on the patron's Fines tab. What I don't understand is why you can only print one line at a time and each receipt shows the total due. Shouldn't there be a way to select multiple lines to print on one receipt? Or not have it show the total due? I have some librarians that find having one line item and a total on the invoice. This might be simply resolved by making the total due not look like it's summing the lines above. -- 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 6

[Bug 13016] New: Add fine grace period by hour
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13016 Bug ID: 13016 Summary: Add fine grace period by hour Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In fine rules, it will be fine to have possibility to add a grace period by hour when loan period is by hour. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 13816] New: Set Overdue letter fine to the overduerules
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13816 Bug ID: 13816 Summary: Set Overdue letter fine to the overduerules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org We need to be able to add a fine for borrowers for each overdueletter we send them. This patch makes the necessary DB modifications to add the fines-columns and CRUD them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 7663] New: batch add barcodes to a list
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7663 Priority: P5 - low Change sponsored?: --- Bug ID: 7663 Assignee: gmcharlt(a)gmail.com Summary: batch add barcodes to a list QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Tools Product: Koha I would be nice if this page: /koha/virtualshelves/shelves.pl?viewshelf=13 had a bigger box so that you could add multiple barcodes at a time (like you can on label maker or the batch modification tool). -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 10198] New: Add the ability to import and export authorized values
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10198 Bug ID: 10198 Summary: Add the ability to import and export authorized values Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathieu.saby(a)univ-rennes2.fr CC: gmcharlt(a)gmail.com We can not import and export easily from staff interface a list of authorized values (in CSV or SQL). It would be useful. M. Saby -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 7802] New: A MySQLism is used to get the current date.
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7802 Priority: P5 - low Change sponsored?: --- Bug ID: 7802 Assignee: gmcharlt(a)gmail.com Summary: A MySQLism is used to get the current date. QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: marc(a)msys.ch Hardware: All Status: NEW Version: unspecified Component: Database Product: Koha To get todays date, the MySQL only function CURDATE() or CURRENT_DATE() is being used in many places. Neither CURDATE() nor CURRENT_DATE() must be used, but instead the standard form CAST(now() AS date). -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 7172] New: Data Persistency
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '15

16 Oct '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7172 Bug #: 7172 Summary: Data Persistency Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 - high Component: Architecture, internals, and plumbing AssignedTo: paul.poulain(a)biblibre.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7119 We need to fix up the code throughout the system to be able to handle data faster-than-CGI processors like Plack, FastCGI or mod_perl. At this time, most of Koha can run okay, but when errors happen, they crash HARD. Some issues than need attention: nested subroutines: mod_perl, and I think other systems, turn each script into a subroutine. If you have subroutines in subroutines (as we do in C4 and some of the scripts), and an inner subroutine modifies a variable declared outside in the outer subroutine, you will get an error "variable will not stay shared". This can sometimes (always?) be fixed by using "our" instead of "my". Or using better coding practices :) memory leaks: some memory may not be released, so a persistent engine could bloat over time. other issues may come up, as well. -- 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 48