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

[Bug 11725] New: Longoverdue cron job seems to not want to charge anymore
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11725 Bug ID: 11725 Summary: Longoverdue cron job seems to not want to charge anymore Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Test plan: Have a book issued to a borrower that is overdue (sometime before 366 days overdue.) Run the longoverdue cron job in a way that the item will be marked as long overdue - I did mine as follows: perl longoverdue.pl --lost 10=2 --mark-returned --charge 2 --confirm That means: mark things that are 10 days overdue with lost value 2, return them from the borrower record, and charge the borrower the replacement cost for realsies. I wasn't able to get the script to charge, I'm either doing it wrong (not apparent, according to the documentation), or it's been broken with the patch for bug 7639, as reverting those changes causes items to be correctly charged again. -- You are receiving this mail because: You are watching all bug changes.

1 1

[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 4530] Circulation & fines rules aren't always applied from most specific to less specific
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4530 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron(a)veron.ch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11892] New: Add controls on overdue notices configuration
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '14

05 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11892 Bug ID: 11892 Summary: Add controls on overdue notices configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In overdue notices configuration : cgi-bin/koha/tools/overduerules.pl. When a rule is set without notice, the line can have delay empty or letter on "No notice". It would be more clear to add a control that forces to set both delay empty and letter on "No notice" to disable a rule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 1993] Task Scheduler Needs Re-write
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '14

04 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1993 wajasu <matted-34813(a)mypacks.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matted-34813(a)mypacks.net --- Comment #44 from wajasu <matted-34813(a)mypacks.net> --- I got it to work by changing the command definition in tools/scheduler.pl my $command = "export KOHA_CONF=\"$CONFIG_NAME\"; export PERL5LIB=" . $base . "; " . $base . "/misc/cronjobs/runreport.pl "; $command = $command . "--format=$format " if $format; $command = $command . "--to='$email' " if $email; $command = $command . $report if $report; AND also added www-data, which was defined in /etc/apache2/envvars (APACHE_RUN_USER) to the /etc/at.allow and no more permission problem I had created an sql report, and did not test email, though without email the report output was seen in the mail box for the www-data user. (su - www-data and then 'mail' and p for print. ) I am just documenting my cursory findings. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4397] display problems (umlauts, ß) with scan index in advanced search
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '14

04 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4397 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4397] display problems (umlauts, ß) with scan index in advanced search
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '14

04 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4397 Marc Véron <veron(a)veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25742|0 |1 is obsolete| | CC| |veron(a)veron.ch -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4397] display problems (umlauts, ß) with scan index in advanced search
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '14

04 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4397 --- Comment #4 from Marc Véron <veron(a)veron.ch> --- Created attachment 25817 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25817&action=edit [Signed-off] Bug 4397: Scan index search results broken for non-latin characters The Zoom specification defines that a ScanSet should provide a way to retrieve terms suitable for displaying and another one for using on further searches [1]. The Net::Z3950::ZOOM implementation actually provides both [2] but we where using the wrong one. Using $scanset->display_term(...) instead of $scanset->term(...) fixes the problem. To test: - Do a index scan search (advanced search > more options > check 'index scan') - Notice non-latin characters are replaced by one or more '@' symbols. - Apply the patch - Re-do the search, everything shows as it should. - Try to follow any of the terms (clicking on them) and notice that it actually gives you relevant results (i.e. is not searching for @!!!!). - Sign off :-D Regards To+ [1] http://zoom.z3950.org/api/zoom-1.4.html#3.6.3 [2] http://search.cpan.org/~mirk/Net-Z3950-ZOOM/lib/ZOOM.pod#term()_/_display_t… Sponsored-by: Universidad Nacional de Cordoba Followed test plan. Patch behaves as expected. Signed-off-by: Marc Véron <veron(a)veron.ch> -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0