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

[Bug 11945] New: Cronjob delete_expired_opac_registrations.pl fails with error in SQL syntax
by bugzilla-daemon＠bugs.koha-community.org 16 Mar '15

16 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11945 Bug ID: 11945 Summary: Cronjob delete_expired_opac_registrations.pl fails with error in SQL syntax Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: larry(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When running the cronjob, delete_expired_opac_registrations.pl on a 3.14 site, I get the following error message: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 6 at /usr/share/koha/bin/cronjobs/delete_expired_opac_registrations.pl line 76. Checking the script, I find this SQL code: my $query = " SELECT borrowernumber FROM borrowers WHERE categorycode = ? AND DATEDIFF( DATE( NOW() ), DATE(dateenrolled) ) = ? ) If I run that SQL statement in the database manually, I get the same error message, e.g.: mysql> select borrowernumber from borrowers where categorycode='SELF' AND DATEDIFF( DATE( NOW() ), DATE(dateenrolled) ) = 7 ); ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 It would appear there's some problem with the DATEDIFF piece of the SELECT statement. - Larry -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 10461] New: tax not taken in to account in the acq budget summaries
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '15

13 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10461 Bug ID: 10461 Summary: tax not taken in to account in the acq budget summaries Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All URL: acqui-home.pl OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com On acqui-home.pl the budget summary is not taking in to account tax rate at all. The code looks something like this: SELECT SUM( COALESCE(unitprice, ecost) * quantity ) AS sum FROM aqorders WHERE budget_id = ? AND quantityreceived > 0 AND datecancellationprinted IS NULL Plus SELECT SUM(shipmentcost) AS sum FROM aqinvoices WHERE shipmentcost_budgetid = ? AND closedate IS NOT NULL Tax rate should be included in this to give an accurate count of what has been spent/ordered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 11821] New: Staff client catalog: delete menu items greyed out without explanation
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '15

13 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11821 Bug ID: 11821 Summary: Staff client catalog: delete menu items greyed out without explanation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org If you view a title in the staff client which has items attached the edit menu item "Delete record" will be greyed out. Like the fix in Bug 2310 a tooltip should be added explaining why. Similarly, menu items which relate to operations on items should be disabled (with explanation) if the record has no items. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 9848] New: SIP tests : fix in 10renew_all.t (additionnal checkin)
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '15

12 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9848 Bug ID: 9848 Summary: SIP tests : fix in 10renew_all.t (additionnal checkin) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: SIP2 Assignee: adrien.saurat(a)biblibre.com Reporter: adrien.saurat(a)biblibre.com CC: colin.campbell(a)ptfs-europe.com [MT10401] An error occurs while trying the "renew all" SIP test, 10renew_all.t: # Failed test 'match leader Renew All: prep: check out 1783B to 1X981' # at /home/asaurat/workspace/versions/community/C4/SIP/t/SIPtest.pm line 204. # Response '121YNY20130319 153138AOVIL|AA1X981|AB1783B|AJL ANGOISSE DU ROI SALOMON|AH20130521 235900|AFItem already checked out to you: renewing item.|AY3AZD551' doesn't match pattern '(?-xism:^121NNY\d{8} {4}\d{6})' Koha sent: 121YNY The test expects: 121NNY 12 = code for "Checkout Response" message 1 = Operation succeeded The three following characters mean: - renewal ok - magnetic data - desensitize We have a difference on the "Renewal ok" field. I found the reason behind this: it happens when you run all the tests at once ("make test"). In this case, this "renew all" test starts with an item already checked out during a former test. The "renew all" test begins with a checkout operation, but as the item is already out, this results in a renewal when it's not expected yet. The solution I can see : adding a "checkin" operation at the very beginning of the test. But to let the test work even when launched alone, we must allow this checkin to be unsuccessfull, it's just part of the preparation before the actual renewal tests. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 11430] New: Search history: Delete selected lines
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '15

11 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11430 Bug ID: 11430 Summary: Search history: Delete selected lines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 10807 adds a search history for authorities and bug 10862 adds the search history on the staff interface. This one allows the user to select the search history lines he wants to delete. -- You are receiving this mail because: You are watching all bug changes.

1 98

[Bug 8603] New: Patron card creator - 'Barcode Type' don't stick in layouts
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '15

10 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8603 Priority: P5 - low Change sponsored?: --- Bug ID: 8603 Assignee: cnighswonger(a)foundations.edu Summary: Patron card creator - 'Barcode Type' don't stick in layouts Severity: minor Classification: Unclassified OS: All Reporter: derrynj(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Label printing Product: Koha To reproduce: 1. Make a new layout 2. Tick "Print card number as barcode" 3. Change 'Barcode Type' to anything other than Code39 4. Save 5. Edit it again 6. Its back to Code39 -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 11400] New: Show "Login as a different user" instead of "Logout" if not enough premissions
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '15

08 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11400 Bug ID: 11400 Summary: Show "Login as a different user" instead of "Logout" if not enough premissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 11146 introduced a way to go back, and have a logout link for the "Not enough permissions" message page. I belive this string change is worth. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 11733] New: "gist" system preference inconsistently treated as single-value or multi-value
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '15

06 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11733 Bug ID: 11733 Summary: "gist" system preference inconsistently treated as single-value or multi-value 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: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The "gist" system preference, which specifies tax rates available for use in various places in acquisitions, lets the user specify multiple values separated by pipe symbols. The first value is taken to be the default tax rate to apply. However, there are some places in the code where it effectively assumes that gist contains only one value: acqui/basketgroup.pl: if ($bookseller->{invoiceincgst} && ! $bookseller->{listincgst} && ( $bookseller->{gstrate} // C4::Co acqui/basketgroup.pl: my $gst = $bookseller->{gstrate} // C4::Context->preference("gist"); acqui/basketgroup.pl: my $pdf = printpdf($basketgroup, $bookseller, $baskets, \%orders, $bookseller->{gstrate} // C4::Context-> acqui/invoice.pl:my $gist = $bookseller->{gstrate} // C4::Context->preference("gist") // 0; acqui/parcel.pl:my $gst = $bookseller->{gstrate} // C4::Context->preference("gist") // 0; and other places where it assumes (correctly) that it can have multiple values: acqui/neworderempty.pl:}, split( '\|', C4::Context->preference("gist") ); acqui/supplier.pl: }, split( '\|', C4::Context->preference("gist") ); Routines should be written for fetching either the list of tax rates or the default tax rate as needed. See also bug 11680. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 5176] New: SIPServer Incorrectly Requires Login over Socket
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '15

06 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5176 Summary: SIPServer Incorrectly Requires Login over Socket Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Comment in the source indicates a mis-reading of the standard. Assuming that over a raw socket connection login will be the first message. Standard states that whether login or another mechanism is used is optional. (It is configurable on 3M units and most others). (If used login should be first but it can be spoofed in our implementation anyway) Use of login should be a configurable option. This may cause problems on flaky connections. -- 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 3

[Bug 12008] New: hold notice can be deleted
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '15

06 Mar '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12008 Bug ID: 12008 Summary: hold notice can be deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Okay this is a strange one. 1. Create a new HOLD notice template for a branch (not for all libraries) 2. Delete that new HOLD notice you created 3. Recreate the HOLD notice template for that branch 4. The HOLD notice for all libraries disappears and in the database the message_transports.branchcode field for HOLD now has the branchcode before it was blank. This causes issues with sending of HOLD notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4