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

[Bug 12916] New: Use of uninitialized values $max and $min in C4/Tags.pm
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '15

09 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12916 Bug ID: 12916 Summary: Use of uninitialized values $max and $min in C4/Tags.pm Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org If tag list is empty, sub stratify_tags issues a warning in opac-error.log because of uninitialized values $max and $min in C4/Tags.pm, line 600 -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 11924] New: warning about hold when item checked in at wrong library
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '15

08 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11924 Bug ID: 11924 Summary: warning about hold when item checked in at wrong library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This was received via email: ------------- I guess what I'm seeing as the problem is this: 1. PatronX places an item on hold for pickup at Library A. 2. Library B sends a copy of the item to Library A. 3. The item is checked in at Library A and Koha switches the status of the item to "Item is waiting for PatronX at Library A." 4. A staff member at Library A hands the item to PatronX and, for whatever reason, the item does not get checked out to PatronX. 5. PatronX uses the item and then returns it to Library C. 6. Staff at Library C checks in the item and Koha does nothing. When you look at the item record it says "Item is waiting for PatronX at Library A." Koha does not change the status of the item, it does not display a "Route to Library A" message, it does not change the holding location. Koha does nothing even though the item does not belong at Library C in any way shape or form. Yes, there is a procedure problem here. At step 4 the staff member at Library A screwed up and let PatronX leave the library building with an item that had not been checked out. What I'd like Koha to do is to give the staff at Library C some kind of alert when step 6 is reached so that staff at Library C know that the item is supposedly on hold at Library A. Since Koha doesn't do _anything_ at checkin, if this kind of mistake is made the error created by staff at Library A can be further complicated if staff at Library C are as inattentive as staff at Library A. So my question is, when an item that is supposed to be on hold and waiting for pickup at one branch gets checked in at a different branch, can Koha display some kind of a message? I really think that it ought to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13320] New: Some prices calculation are done in ttemplate side
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '15

06 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13320 Bug ID: 13320 Summary: Some prices calculation are done in ttemplate side Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 12165] New: Add description of charges (bug 2546) to Bootstrap OPAC
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '15

06 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12165 Bug ID: 12165 Summary: Add description of charges (bug 2546) to Bootstrap OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr It looks like we forgot to fix the bootstrap templates in bug 2546: Copying test plan from the other bug: The descriptions for charges are stored in English in the DB (accountlines.description). So they are not translatable. This patch removes the descriptions automatically added and generates the string in the template. Test plan: 1/ Execute the updatedatabase entry. 2/ Verify in the following pages the description is consistent: - members/pay.pl?borrowernumber=XXXX - members/boraccount.pl?borrowernumber=XXXX - opac-account.pl 3/ Launch the translate script and update the po files in order to translate the new strings. 4/ Verify the strings are translated in the interface. The database bits for this are done, we only need to update the templates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 13262] New: Add parameters to XSLT Handler transform method
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '15

05 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13262 Bug ID: 13262 Summary: Add parameters to XSLT Handler transform method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The XML::LibXSLT transform method takes a XSLT and an optional hash of key => value pairs to use in the XSLT as parameters. This enhancement would allow you to pass parameters to the XSLT when using the Koha::XSLT_Handler::transform method as well. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 12601] New: aqorders.budget_id should be a foreign key
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '15

05 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12601 Bug ID: 12601 Summary: aqorders.budget_id should be a foreign key Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When creating an order, the fund value is mandatory but the DB structure does not show this constraint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 12975] New: Refactor VAT and price calculation - basketgroup page
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '15

05 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12975 Bug ID: 12975 Summary: Refactor VAT and price calculation - basketgroup page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 Bug 12969 introduces a subroutine to centralize the VAT and price calculation. The basketgroup page should use it. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 12908] New: Add a German RELTERMS authorized value list to the web installer
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12908 Bug ID: 12908 Summary: Add a German RELTERMS authorized value list to the web installer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The German web installer is missing a list of RELTERMS authorized values. (similar to bug 12299) -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 6254] New: can't set patron privacy by default
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6254 Bug #: 6254 Summary: can't set patron privacy by default Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you do a bulk patron import you can choose a privacy setting for your patrons, but when you create a new patron you can't. Many libraries want the default to be 'Never' and have the patrons opt in - while others want the patrons to choose to opt-out instead. Given this librarians should be able to set the default per patron or patron category and then never be allowed to edit that once it's set (in order to let the patron have control over the preference). -- 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 60

[Bug 12568] New: Improve visibility of successful renewal via opac
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12568 Bug ID: 12568 Summary: Improve visibility of successful renewal via opac Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, when a patron renews an item via the opac, the only feedback the patron receives when a renewal is successful is an updated value for the due date of the item. This subtle indication of success may go unnoticed by some patrons. We should add a more prominent way to indicate an item was renewed successfully. -- You are receiving this mail because: You are watching all bug changes.

1 25