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

[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 8619] New: Remove hidelostitems syspref
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8619 Priority: P5 - low Change sponsored?: --- Bug ID: 8619 Assignee: oleonard(a)myacpl.org Summary: Remove hidelostitems syspref Severity: enhancement Classification: Unclassified OS: All Reporter: fridolyn.somers(a)biblibre.com Hardware: All Status: NEW Version: master Component: OPAC Product: Koha With 'OpacHiddenItems' system preference, you can reproduce what's managed by 'hidelostitems' system preference. For example, if LOST values are 0,1,2,3 (0 meaning not lost), you can use in OpacHiddenItems : itemslost [1, 2, 3]. So hidelostitems is now deprecated since OpacHiddenItems is more rich. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7456] New: itypes with similar codes throw off search results
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7456 Bug #: 7456 Summary: itypes with similar codes throw off search results Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: thatcher.rea(a)bywatersolutions.com QAContact: ian.walls(a)bywatersolutions.com When performing a search for itype "BOOK", items with the itype code of "E-BOOK" appears in the opac search results. The itype codes are defined as follows: http://screencast.com/t/6I162l0m3MOm I created a new itype code of "E-BK", applied it to an item, and it no longer displays in a search limited to itype code "BOOK". Similarly named itype codes are being included in search results. It didn't catch the other itypes, because their codes do not include the string of "book". How to test: 1. create an itype "test" 2. create anohter itype code "e-test" 3. create 2 items (one with itype test, one with itype e-test) 4. index 5. do an advanced search limited by itype 'test' You should get both items. :T -- 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 5

[Bug 6869] New: Batch item modification fails if accented characters are used in the modification form.
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6869 Bug #: 6869 Summary: Batch item modification fails if accented characters are used in the modification form. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5428 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5428 Corrects a problem in batchMod.pl when accented characters are used. When modifying multiple items in batchMod.pl, the batch modification fails if accented characters are used in any of the fields of the modification form. For example, when modifying two items by adding "RÉSERVE" in the Note subfield ($z), the progress bars gets stuck at 50% and the items are nor modified. Seems to be an encoding problem with MARC::Record::new_from_xml. Using utf8::encode before new_from_xml seems to fix the problem. Patch attached. -- 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 10

[Bug 6710] New: lists of lists in Alpha order
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '14

03 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6710 Bug #: 6710 Summary: lists of lists in Alpha order Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org When you click on the button for lists on the OPAC and the pull down menu on the search results in the staff and opac it would be great if those lists were listed in alphabetical order by title of list. Right now it seems kind of random .. maybe the order in which the lists were created? -- 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 8491] New: Warning of Modern::Perl raised by koha_perl_deps script
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '14

27 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8491 Priority: P5 - low Change sponsored?: --- Bug ID: 8491 Assignee: gmcharlt(a)gmail.com Summary: Warning of Modern::Perl raised by koha_perl_deps script Severity: enhancement Classification: Unclassified OS: All Reporter: m.de.rooy(a)rijksmuseum.nl Hardware: All Status: NEW Version: master Component: Command-line Utilities Product: Koha The actual error is (with perl 5.14.2 and Modern::Perl==1.20120130): [Fri Jul 20 16:37:07 2012] koha_perl_deps.pl: Use of uninitialized value $version in numeric lt (<) at /usr/local/share/perl5/Modern/Perl.pm line 25. [Fri Jul 20 16:37:07 2012] koha_perl_deps.pl: Use of uninitialized value $version in numeric lt (<) at /usr/local/share/perl5/Modern/Perl.pm line 25. As Jonathan Druart pointed out in bug 7368, it is caused by the way this module handles version numbers. So it seems like an error in Modern::Perl although its docs state that it is not necessary to pass a version or a year to Modern::Perl. AFAIK we are not passing numbers to Modern::Perl in our Koha use statements. But when I test that in a simple script, I do not even raise this warning. What makes koha_perl_deps do raise that warning? -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 5439] New: 3M RFID sensitization
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '14

27 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5439 Summary: 3M RFID sensitization Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Hook-up_with_3M_se nsitization_solution OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Hook-up with 3M sensitivity solutions so that when you checkout an item in Koha it sends a code (LL) to the 3M system to switch it to Sensitize OFF, and when you checkin an item in Koha it sends a code (RR) to switch the 3M hardware to Sensitize ON. Note : some other sensitivity tools seems underway. Need some clarification ! -- 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 2

[Bug 7608] New: Manual history is always 'enabled'
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '14

26 Feb '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7608 Bug #: 7608 Summary: Manual history is always 'enabled' Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha.sekjal(a)gmail.com To reproduce: - Enter a new subscription in serials, make sure the manual history checkbox is not touched and no data is entered in that section. - The serial summary page will show 'Manual history: Enabled' - Editing the subscription will always show the manual history fields expanded. -- 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 11