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

[Bug 766] Use of CGI::scrolling_list prevents customization in template
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=766 --- Comment #15 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- Created attachment 25906 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25906&action=edit Bug 766: Use the method plugin to generate sort dropdown list - memberentry Now we can use the method plugin from the memberentry form. Test plan: 1/ Create a patron and verify sort1 and sort2 dropdown list are correctly generated. 2/ Select values. 3/ Save. 4/ Edit the patron and verify the selected values are displayed. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 766] Use of CGI::scrolling_list prevents customization in template
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=766 --- Comment #14 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- Created attachment 25905 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25905&action=edit Bug 766: Create a plugin routine to build dropdown list On this way, dropdown list could be generated from the templates. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 766] Use of CGI::scrolling_list prevents customization in template
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=766 --- Comment #13 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- Created attachment 25904 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25904&action=edit Bug 766: Move GetAuthvalueDropbox to C4::Koha GetAuthvalueDropbox is in C4::Budgets, this does not make sense. Only acqui/fetch_sort_dropbox.pl call GetAuthvalueDropbox without using C4::Koha. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10679] New: Lists interface offers delete option when user doesn't have permission
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10679 Bug ID: 10679 Summary: Lists interface offers delete option when user doesn't have permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Lists Assignee: m.de.rooy(a)rijksmuseum.nl Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In both the OPAC and the staff client a "allowremovingitems" variable is used in the template to determine whether the logged in user should be able to delete items from a list. In both the OPAC and staff client this variable is true when it should be false. Fortunately the user can't actually remove something from the list. Instead the page returns an error message. However, the "remove" option should not be visible in that case. To confirm this bug, log in to the OPAC or staff client and open a public list which was created by another user. The "remove from list" option will be available but submitting the form will return an error like "You could not delete any selected items from this shelf." -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 5901] New: Make virtualshelves permissions more granular
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5901 Bug #: 5901 Summary: Make virtualshelves permissions more granular Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Virtual Shelves AssignedTo: gmcharlt(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org At the moment the virtualshelves system parameter is an ON/OFF option. I think this needs to be more granular: - no lists - lists for staff only (= virtualshelves OFF now) - allow patrons to create private lists - allow patrons to create private and public lists (= virtuelshelves ON now) Good or bad idea? Do we need more than that? -- 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 8

[Bug 7495] New: Tax calculations problem for new orders.
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7495 Bug #: 7495 Summary: Tax calculations problem for new orders. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: fcapovilla(a)live.ca QAContact: koha.sekjal(a)gmail.com When creating a new order, the automatic tax calculations may sometimes be wrong because of loss of precision. Example : With gist=0, create a new order and put 18.99 into the "Vendor price" field. The "Budgeted cost" and "Total" fields are automatically set to 18.98 when they should be 19.99 The same happens with 16.99 . Possible cause of the problem : http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-r… Here are some utility functions that could be used to correct the problem : function to_Cents(val) { return Math.round(val*100); } function to_Dollars(val) { return (Math.round(val)/100).toFixed(2); } -- 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 10

[Bug 8465] New: CancelReserve sub is doing wrong
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8465 Priority: P5 - low Change sponsored?: --- Bug ID: 8465 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: CancelReserve sub is doing wrong Severity: critical Classification: Unclassified OS: All Reporter: christophe.croullebois(a)biblibre.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha In request.pl when you cancel a waiting hold, with the red cross,the next becomes "waiting", but: in the same page, the details column shows "No Barcode " in detail.pl, the status column shows "available" that is bad too, but: behind the scene, it's worse, because the CancelReserve function is poorly formated. The matter is that this sub puts a "W" on the next hold, that is impossible due to many constraints An other point, the sub increases priority for all other holds, that is good, except in one case: if we delete an hold with priority=0 and found=W the next waiting with priority=1 will be 0, and that is not good. So I have just corrected that and cleaned the code. After discussions, I have decided to avoid a manual checkin of the item. So, in the case of deleting a waiting hold, no need to checkin the item, if we have an hold following, a requester will propose to transfer or to confirm the hold. cleaning CancelReserve API : the biblionumber is retrieved in the SELECT * FROM reserves WHERE reservenumber = ?' at the beginning of the sub, so removing it from API. **************************************************************************** To test : * put 2 different holds on a biblio with 1 item * checkin and confirm the first hold * all is correct you can see it in the piority column "Waiting" * now use the red cross on the right to cancel this hold * check request.pl and detail.pl you'll see the results of the bug. Thx for testing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 2865] Acquisitions: GST not calculating correctly.
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2865 Jonathan Druart <jonathan.druart(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |RESOLVED Resolution|--- |INVALID --- Comment #9 from Jonathan Druart <jonathan.druart(a)biblibre.com> --- This one is too old. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11893] New: Get rid of warning from IsSuperLibrarian
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11893 Bug ID: 11893 Summary: Get rid of warning from IsSuperLibrarian Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Add a new patron. Do not set permissions yet. You will see lots of warnings like: Use of uninitialized value in modulus (%) at /usr/share/koha/testclone/C4/Context.pm line 1254. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 3144] anti-spam for opac-suggestions
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '14

06 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144 Christopher Vella <chris(a)calyx.net.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris(a)calyx.net.au --- Comment #4 from Christopher Vella <chris(a)calyx.net.au> --- Hi everyone I have been investigating this issue today for one of Calyx's clients. I decided to do a bit of reading up on the issue of spam protection. reCAPTCHA was the first solution that came to mind, however valid points about accessibility issues have already been made. What about the possibility of implementing a negative captcha? That way OPACs remain accessible. It would also mean we don't have to deal with the false positive detection of suggestions (as with analytical spam detection). The only downside I can see with this would be a bruteforce tool that tries ignoring particular fields or a custom coded spam bot (which seems very unlikely considering the value of the target). I also like the http://visualcaptcha.net/ project. Chris -- You are receiving this mail because: You are watching all bug changes.

1 0