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

[Bug 23310] New: Noisy Koha::Biblio
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23310 Bug ID: 23310 Summary: Noisy Koha::Biblio Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Sometimes 254$a and 254$b are not both defined. This creates noise in Koha/Biblio.pm around line 579ish. This is repeatable by running the gambit of tests and reading the plack-error log file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 22874] New: Limit to available items doesn't work with elasticsearch 6.x
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22874 Bug ID: 22874 Summary: Limit to available items doesn't work with elasticsearch 6.x Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com Target Milestone: --- Currently we send "onloan:0" to ES to get records with available items. But ES 6 does not considers 0 as a valid boolean. On ES 6.x: onloan:0 => doesn't work onloan:false => works On ES 5.x: onloan:0 => works onloan:false => works So it seems we can have compatibility for both ES 5 and ES 6 by using false instead of 0. Patch is coming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 22114] New: Untranslatable "Patron note:" in checkout.js
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22114 Bug ID: 22114 Summary: Untranslatable "Patron note:" in checkout.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Target Milestone: --- just noticed a line in checkout.js that contains a string: $('.patron_note_' + data.itemnumber).html("Patron note: " + data.patronnote); .js files are not translated currently. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22377] New: Lost fines may not be refunded if another patron has a writeoff for the same item
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22377 Bug ID: 22377 Summary: Lost fines may not be refunded if another patron has a writeoff for the same item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1 - Checkout an item to Patron A, backdate the due date and run fines to generate an overdue 2 - Return the item 3 - Checkout the item to Patron B, mark it lost and ensure a fine is generated 4 - In the DB set the date i=on the lost fine to yesterday 5 - Writeoff the fine for Patron A 6 - Return the item 7 - It is no longer lost, but the lost fine is not refunded -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 23633] New: Filter out historical charges by default on a users 'your charges' page
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23633 Bug ID: 23633 Summary: Filter out historical charges by default on a users 'your charges' page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The 'your charges' OPAC page display all charges (paid for or otherwise) that the user has ever had. It's also the page where, if enabled, a user can initiate an online payment. If there's is a large history of paid charges displayed then it can be cumbersome to pick out the charges owed and scroll to the bottom of the page to reach the pay now buttons. I propose we filter the table by default to just outstanding account lines and allow the full view via a button/checkbox. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 23671] New: Elasticsearch shouldn't throw exception on an uppercase subfield identifier
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23671 Bug ID: 23671 Summary: Elasticsearch shouldn't throw exception on an uppercase subfield identifier Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicolas.legrand(a)bulac.fr Depends on: 23670 MARC 21 specifies a subfield identifier “may be any any lowercase alphabetic or numeric character” (https://www.loc.gov/marc/96principl.html section 8.4.2). It is not that clear for Unimarc or even for ISO 2709 itself. Our catalogue in Unimarc use uppercase alphabetic subfield identifier for items. When we try to index it with Elasticsearch, it throws an exception (well, it tries to, this is fixed by Bug 23670). We think Elasticsearch shouldn't be picky about uppercase alphabetic subfield identifier, especially when Koha permits their creation in the MARC Framework or in the Elasticsearch mapping. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23670 [Bug 23670] Load Koha::Exceptions::ElasticSearch module in Koha::SearchEngine::Elasticsearch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 23670] New: Load Koha::Exceptions::ElasticSearch module in Koha::SearchEngine::Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '19

28 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23670 Bug ID: 23670 Summary: Load Koha::Exceptions::ElasticSearch module in Koha::SearchEngine::Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicolas.legrand(a)bulac.fr When your mapping includes an Invalid MARC field expression, it tries to throw an exception with Koha::Exceptions::Elasticsearch::MARCFieldExprParseError. But since Koha::Exceptions::Elasticsearch isn't loaded in Koha::SearchEngine::Elasticsearch, it dies like this: Can't locate Koha/Exceptions/Elasticsearch/MARCFieldExprParseError.pm in @INC (you may need to install the Koha::Exceptions::Elasticsearch::MARCFieldExprParseError module) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 22862] New: Normalize SMS messaging numbers before validating them
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '19

25 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22862 Bug ID: 22862 Summary: Normalize SMS messaging numbers before validating them Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Librarians often copy and paste patron data, including phone numbers. SMS phone numbers are now being validated to conform to the E.164 specification. It would be nice to try to normalize that data by stripping non-numeric data from the paste (i.e. dashes, parens, etc ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 23413] New: Add a holds routine to Koha::Items to fetch related holds
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '19

25 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23413 Bug ID: 23413 Summary: Add a holds routine to Koha::Items to fetch related holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 23170] New: in j2a.pl when a patron passes to an adult the name and surname of Guarantor stay on account
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '19

25 Oct '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23170 Bug ID: 23170 Summary: in j2a.pl when a patron passes to an adult the name and surname of Guarantor stay on account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: christophe.croullebois(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- To test : 1° run the j2a.pl with at least 1 juvenile/child patron who have the age to be moved to adult 2° on Patron details you see 'Guarantor' still with name and surname -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5