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

[Bug 7245] New: Errors in MySQL tables population with mandatory data for italian installation
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7245 Bug #: 7245 Summary: Errors in MySQL tables population with mandatory data for italian installation Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: fabio.tian(a)gmail.com QAContact: ian.walls(a)bywatersolutions.com Created attachment 6337 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6337 screenshot of errors in web installer While installing italian and UNIMARC version of Koha via web installer, two errors occur: ERROR 1136 (21S01) and ERROR 1064 (42000). Some tables can't be populated with mandatory data. Errors are related to files sample_itemtypes.sql and unimarc_framework.sql (/usr/share/koha/intranet/cgi-bin/installer/data/mysql/it-IT/ and subdirectories). -- 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 25

[Bug 7831] New: In neworderempty budget drop down budgets should appear in a rational order
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7831 Priority: P5 - low Change sponsored?: --- Bug ID: 7831 Assignee: henridamien(a)koha-fr.org Summary: In neworderempty budget drop down budgets should appear in a rational order QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: colin.campbell(a)ptfs-europe.com Hardware: All Status: NEW Version: master Component: Acquisitions Product: Koha Budgets are listed in the fund selection dropdown in an order which does not make sense for the user, To improve this the budgets array should be sorted bu the visible text field -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 2034] circ/billing.pl needs the more complex code to achieve goals for large data sets
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2034 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|rel_3_6 |rel_3_8 --- Comment #6 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> --- This will not be included in 3.6.x, just in case someone is using the script somehow. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7886] New: C4/ShelfBrowser slow SQL performance
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7886 Priority: P5 - low Change sponsored?: --- Bug ID: 7886 Assignee: oleonard(a)myacpl.org Summary: C4/ShelfBrowser slow SQL performance QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: dpavlin(a)rot13.org Hardware: All Status: NEW Version: rel_3_6 Component: OPAC Product: Koha While profiling Koha while writing http://wiki.koha-community.org/wiki/Performance I noticed that ShelfBrowser uses two SQL queries: SELECT * FROM items WHERE ((cn_sort = ? AND itemnumber < ?) OR cn_sort < ?) AND homebranch = ? AND location = ? AND ccode = ? ORDER BY cn_sort DESC, itemnumber LIMIT ? SELECT * FROM items WHERE ((cn_sort = ? AND itemnumber >= ?) OR cn_sort ?) AND homebranch = ? AND location = ? AND ccode = ? ORDER BY cn_sort, itemnumber LIMIT ? Each of this queries takes around 1.5 second on our catalogue with ~340000 items (that's 3 seconds of total query time). homebranch already has index, and adding following indexes: create index items_location on items(location) ; create index items_ccode on items(ccode) ; improves performance by 0.5 seconds (total of 1 second for both queries) since MySQL is able to use index_merge intersect(items_ccode,homebranch,items_location) Since indexes use additional disk space, I'm not sure if this change is applicable to all Koha installations, but I'm looking for feedback. Does it make sense to submit patch with schema change? Ideal solution would be to run those queries once, but for 50 or 100 results, cache results and browse through cache. This would involve one-time penalty hit for first query, but following browsing would be much faster. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 7888] New: Permission for "change password" button in circ toolbar should be "borrowers" instead of "staffaccess"
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7888 Priority: P4 Change sponsored?: --- Bug ID: 7888 CC: gmcharlt(a)gmail.com Assignee: wizzyrea(a)gmail.com Summary: Permission for "change password" button in circ toolbar should be "borrowers" instead of "staffaccess" QA Contact: koha.sekjal(a)gmail.com Severity: minor Classification: Unclassified OS: All Reporter: wizzyrea(a)gmail.com Hardware: All Status: ASSIGNED Version: rel_3_6 Component: Patrons Product: Koha The "set password" button in the circ-toolbar.inc is now hidden from users that do not have can_user_staffaccess - I don't think this makes sense - a user with edit borrowers permission can change the password from "edit patron," so for consistency, the button should work on the same permission level. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 7766] New: C4/Auth.pm emits debug output to STDOUT
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7766 Priority: P5 - low Change sponsored?: --- Bug ID: 7766 CC: dpavlin(a)rot13.org Assignee: gmcharlt(a)gmail.com Summary: C4/Auth.pm emits debug output to STDOUT QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: dpavlin(a)rot13.org Hardware: All Status: NEW Version: rel_3_8 Component: Authentication Product: Koha Created attachment 8384 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8384&action=edit proposed patch This breaks plack deployments because it emits output to STDOUT before headers are sent -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7885] New: Change filename of TransferLog suggested by packages to fit with logrotate
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7885 Priority: P5 - low Change sponsored?: --- Bug ID: 7885 Assignee: robin(a)catalyst.net.nz Summary: Change filename of TransferLog suggested by packages to fit with logrotate QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: magnus(a)enger.priv.no Hardware: All Status: NEW Version: master Component: Packaging Product: Koha debian/templates/apache-site.conf.in creates a per-site Apache conf file that contains this: # TransferLog /var/log/koha/__KOHASITE__/opac-access_log If this line is simply uncommented (by naive people like me), it will result in an access log like this: /var/log/koha/mysite/opac-access_log Now, the packages set up logrotate, but it only looks for this pattern: /var/log/koha/*/*.log which results in the TransferLog not getting picked up by logrotate. Is there a specific reason for doing it this way, or would it be better if we changed the Apache conf file to this: # TransferLog /var/log/koha/__KOHASITE__/opac-access.log --- Apache conf template: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=debian/templates/… logrotate config: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=debian/koha-commo… -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 7866] New: Rank not used in Z39.50 search page
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7866 Priority: P5 - low Change sponsored?: --- Bug ID: 7866 Assignee: adrien.saurat(a)biblibre.com Summary: Rank not used in Z39.50 search page QA Contact: koha.sekjal(a)gmail.com Severity: minor Classification: Unclassified OS: All Reporter: adrien.saurat(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Cataloging Product: Koha In the Z39.50 search screen, the available Z39.50 are displayed as a non-ordered list. They should be ranked by "rank", and then maybe by "name". TEST PLAN 1) Be sure that you have at least a few Z39.50 servers (Administration -> 239.50 clients targets) Each server should have a defined rank. For best results, have at least 4 servers with ranks 1, 2, 3, 4 and so on (but beginning with mixed letters, the 1st ranked server could begin with a "Z"). 2) Go to the cataloging section, add a MARC record, do a Z39.50 search. The servers list is not ordered by rank. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 5974] New: Bogus auth check for "StaffMember" role
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5974 Bug #: 5974 Summary: Bogus auth check for "StaffMember" role Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: ASSIGNED Severity: minor Priority: P5 Component: Patrons AssignedTo: oleonard(a)myacpl.org ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com In circ-toolbar.inc:   new YAHOO.widget.Button("changepassword");   new YAHOO.widget.Button("changepassword");  Besides being pointless, this refers to a "StaffMember" variable which is only defined in one place, moremember.pl, based only on the patron category. A remnant of a time before granular permissions? -- 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 30

[Bug 7239] New: Acquisitions basket, add order to basket, from new, Source of classification or shelving scheme being blank caused internal error
by bugzilla-daemon＠bugs.koha-community.org 24 May '12

24 May '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7239 Bug #: 7239 Summary: Acquisitions basket, add order to basket, from new, Source of classification or shelving scheme being blank caused internal error Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: chrish(a)catalyst.net.nz QAContact: ian.walls(a)bywatersolutions.com When creating a new basket in Acquisitions the fields "Title" and "quantity" are red (indicating mandatory) so I fill them in and click save, however if you do not select an option from "Source of classification or shelving scheme" (leaving it blank) then after clicking save an internal error occurs[1]. Using the back button to go back and fill in this field then clicking save will then show a basket with an excess entry (as the entry from before, although it caused an error, appears to still be added to the basket). Should "Source of classification or shelving scheme" be marked mandatory, or is this a bug in the display of the basket? [1] on mykoha.co.nz it is mentioned as "an internal error occured", however using my local setup I get "mismatched tag at line 7, column 2, byte 273 at /usr/lib/perl5/XML/Parser.pm line 187". -- 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 18