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

[Bug 20626] New: Fines are recalculated and removed on SIP checkin
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '20

06 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20626 Bug ID: 20626 Summary: Fines are recalculated and removed on SIP checkin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When a patron has an accruing fine (code FU) for an item, and that item is returned, there are some parts of the logic that causes unexpected consequences. All of the following assumes CalculateFinesOnReturn is not active. The following happens when the issuing rule fine value is set to 0. If the return is made via the staff interface, and no explicit return date is set, the item is returned, and the fine is changed to code F, but amount remains. If the return is made via the staff interface, with an explicit return date, the item is returned, and the fine is changed to code F, but the amount is cleared. This is documented in a comment in the code as the expected behaviour. If the return is made via the SIP2 protocol, it will always have an explicit return date, because the date is set from the SIP reply. Therefor the amount will be cleared. This is unexpected since the SIP checkins aren't backdated returns. When the issuing rule fine value is set to higher than 0, similar things happen, except it will change the fine instead of clearing it. Again, this is unexpected for SIP checkin. With no expected backdating, and CalculateFinesOnReturn disabled, I'd expect fine amounts to remain untouched. A very simple fix is of course to change C4/SIP/ILS/Transaction/Checkin.pm and simply not send $return_date to AddReturn(). I don't know if this is a proper solution or not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 13665] Retrieve facets from zebra is slow
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '20

06 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13665 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16972] New: ./misc/ sip_cli_emulator.pl should list mandatory vs. optional command line options in its usage section.
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '20

06 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16972 Bug ID: 16972 Summary: ./misc/sip_cli_emulator.pl should list mandatory vs. optional command line options in its usage section. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz As far as I can tell, the following options are mandatory: -a (address) -p (port) -su (sip user) -sp (sip password) -l (sip location/institution) The sip terminator (-t) is not mandatory, but getting it wrong hangs the script without warning. The usage would look like this, more or less: Usage: $0 -a <address> -p <port> -su <sip user> -sp <sip port> -l <location> [--patron <patron barcode>] [--password <patron password>] [-i <item barcode>] [-fa] [-m <message>] [-h] -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '20

06 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #27 from David Cook <dcook(a)prosentient.com.au> --- I have been thinking that maybe we should modularize search more so that it would make it easier to customize behaviour, unit test, and swap different backends in/out, but... I think one of the biggest struggles we face is that Koha doesn't really have a search query language. We have something like CCL, but it's not CCL, and our compensating for that fact leads to problems. And without a real query language, we don't have a real query parser, and without a real query parser, it's hard to safely and programmatically alter the queries. But... I don't really have a solution in mind either. Sometimes, I hope that we'll just get rid of Zebra, and then we can just focus on Elasticsearch, and maybe change our search query syntax to be safer, easier to parse, and easier to integrate with Elasticsearch. I think it would be a breaking change away from the Zebra CCL-like search syntax we've used... but that would probably be a good thing. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '20

06 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #26 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #25) > > What about the patch? Was not it suppose to fix the issue? Oh yeah... apparently I wrote that patch 6 years ago. I didn't realize I was even the author of it. But according to my comment from https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430#c6, I think my patch would actually break some searches in Koha where older versions of Zebra are used (ie < 2.0.62). I think the koha-common package uses 2.0.59 by default, so probably not a good idea to use this patch. I think my hopelessness with Search.pm led me to making this comment https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430#c9 and opening this bug yesterday: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24586 I think the problem with Koha's search is that it looks like it works in many cases, so attempts to fix it will change the familiar behaviour, and people will complain. But I don't think it's possible to fix it and maintain backwards compatibility with current behaviour. The hardest part for me is finding the resources to fix it. Because it mostly works, I don't have a client-led or employer-led mandate to spend my resources fixing it. I wish I could do it out of the goodness of my heart, but my heart has other priorities. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23274] New: t/db_dependent/XISBN.t fails with Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23274 Bug ID: 23274 Summary: t/db_dependent/XISBN.t fails with Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org What is says in the title: - Run t/db_dependent/XISBN.t - tests pass - Activate Elasticsearch - t/db_dependent/XISBN.t fails -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 14759] Replacement for Text::Unaccent
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14759 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable CC| |lucas(a)bywatersolutions.com Version(s)|20.05.00, 19.11.03 |20.05.00, 19.11.03, released in| |19.05.08 --- Comment #49 from Lucas Gass <lucas(a)bywatersolutions.com> --- backported to 19.05.x for 19.05.08 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10352] Cataloguing log search mixing itemnumber/bibnumber
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10352 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com Status|Pushed to stable |Pushed to oldstable Version(s)|20.05.00, 19.11.03 |20.05.00, 19.11.03, released in| |19.05.08 --- Comment #34 from Lucas Gass <lucas(a)bywatersolutions.com> --- backported to 19.05.x for 19.05.08 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24394] New: Typo when adding a new cash register
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24394 Bug ID: 24394 Summary: Typo when adding a new cash register Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When adding a new cash register, it says "Add new cash_register" with an underscore. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 24123] New: bulkmarcimport.pl doesn't support UTF-8 encoded MARCXML records
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24123 Bug ID: 24123 Summary: bulkmarcimport.pl doesn't support UTF-8 encoded MARCXML records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, robin(a)catalyst.net.nz Importing an UTF-8 encoded MARC21 MARCXML record that has leader value in position 09 equal 'a' (unicode) makes non-ascii characters like 'ä' to be replaced with character '�'. The command being run is > misc/migration_tools/bulkmarcimport.pl -biblios -file record.marcxml -m=MARCXML -v -v I tracked this problem down to the line > $MARC::File::XML::_load_args{BinaryEncoding} = 'utf-8'; If you add that line again as first thing in the RECORD label block further down in the bulkmarcimport.pl the problem is fixed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19