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

[Bug 16528] New: Add ability to parallel process fines to fines.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '20

29 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16528 Bug ID: 16528 Summary: Add ability to parallel process fines to fines.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On very large sites with thousands of overdue items, fines.pl may take an incredibly long time to complete. It may be possible to speed up fines.pl by allowing it to fork children that run in parallel. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 24450] New: Clarify wording when unable to cancel order and delete record
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '20

26 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24450 Bug ID: 24450 Summary: Clarify wording when unable to cancel order and delete record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On basket.pl, when looking at an order line for a bib that has been used in more than one uncanceled order we get the message "Can't cancel order and delete catalog record X order(s) left" This message doesn't do a very good job of conveying what's being counted. X here is the count of uncanceled orders for this bib, minus 1. In other words, how many orders other than the one you're currently looking at use this bib. I'd suggest changing "X order(s) left" to "Used in X other order(s)." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 24109] New: Elasticsearch - Advanced search limit by shelving location uses AND instead of OR
by bugzilla-daemon＠bugs.koha-community.org 26 Jun '20

26 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24109 Bug ID: 24109 Summary: Elasticsearch - Advanced search limit by shelving location uses AND instead of OR Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: mkstephens(a)lancasterseminary.edu When performing an advanced catalog search, the limits for item type and collection are formed into a query string with OR, while the limits for shelving location are formed into the query string with AND. This prevents searching multiple locations at once and is also confusing since the behavior is different from the other limit tabs and is accompanied by the same instruction, "Limit to any of the following." Steps to replicate: 1. In the advanced catalog search, select two limits on the item types tab. Perform search. Note the search query was constructed with OR. 2. Return to the advanced catalog search and clear fields. Select two limits on the shelving location tab. Perform search. Note the search query was constructed with AND. 3. Return to the advanced catalog search and clear fields. Select two limits on the collections tab. Perform search. Note the search query was constructed with OR. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 19588] New: There is no ILL requests history
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '20

25 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19588 Bug ID: 19588 Summary: There is no ILL requests history Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 7317 When a request is deleted, the row is removed from illrequests. Is that expected? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 [Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 23309] New: Can't add new subfields to bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23309 Bug ID: 23309 Summary: Can't add new subfields to bibliographic frameworks Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When I try to add a new a new subfield to a tag in the bibliographic MARC frameworks, it doesn't save. Tested on a sandbox, found this in the logs: DBD::mysql::st execute failed: Incorrect integer value: '' for column 'hidden' at row 1 [for Statement " insert into marc_subfield_structure (tagfield,tagsubfield,liblibrarian,libopac,repeatable,mandatory,kohafield,tab,seealso,authorised_value,authtypecode,value_builder,hidden,isurl,frameworkcode, link,defaultvalue,maxlength) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) " with ParamValues: 0="922", 1="n", 2="k", 3="k", 4=0, 5=0, 6="", 7="-1", 8=undef, 9="", 10="", 11="", 12="", 13=0, 14="", 15="", 16="", 17="9999"] at /kohadevbox/koha/admin/marc_subfields_structure.pl line 316. DBD::mysql::st execute failed: Incorrect integer value: '' for column 'hidden' at row 1 [for Statement " insert into marc_subfield_structure (tagfield,tagsubfield,liblibrarian,libopac,repeatable,mandatory,kohafield,tab,seealso,authorised_value,authtypecode,value_builder,hidden,isurl,frameworkcode, link,defaultvalue,maxlength) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) " with ParamValues: 0="941", 1="k", 2="k", 3="k", 4=0, 5=0, 6="", 7="-1", 8=undef, 9="", 10="", 11="", 12="", 13=0, 14="", 15="", 16="", 17="9999"] at /kohadevbox/koha/admin/marc_subfields_structure.pl line 316. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 17232] New: Subfield default values are not ported when creating a new framework from an old one
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '20

24 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17232 Bug ID: 17232 Summary: Subfield default values are not ported when creating a new framework from an old one Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating a new bibliographic MARC21 framework from an old one, any default values set for subfields in the old framework are not ported to the newly created framework. They have to be reset. To reproduce: - Set a default value in an existing bibliographic MARC21 framework, e.g. 040$a to your institution's MARC code. - Create a new framework based on that one - Create a new record using that new framework: the default value is not set. - Upon checking the database table marc_subfield_structure (e.g. WHERE tagfield = 40 and tagsubfield = 'a'), notice there is no defaultvalue set in that subfield in the new framework. This issue occurs in a package install of version 16.05 on Debian. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 22571] New: Bug in Perl module "Koha::SimpleMARC::field_equals"
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22571 Bug ID: 22571 Summary: Bug in Perl module "Koha::SimpleMARC::field_equals" Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- After successfully creating a MARC modification template in Koha menu "Tools > Batch record modification" with the following action: Add new field 041$a with value ger if 008 matches RegEx m/^...................................ger..$/ the action is run over a given record and Koha says that the bibliographic record has successfully been modified - but in fact nothing has changed, thus no new MARC 041$a is created. According to Jonathan Druart (in mailinglist "Koha", 21.03.2019 17:12) this is a bug in Perl module "Koha::SimpleMARC::field_equals". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 23825] New: Object.t is failing - Exception not caught
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '20

23 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23825 Bug ID: 23825 Summary: Object.t is failing - Exception not caught Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Something weird here: kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ prove t/db_dependent/Koha/Object.t t/db_dependent/Koha/Object.t .. 3/11 # Failed test 'Exception thrown correctly' # at t/db_dependent/Koha/Object.t line 359. # expecting: Koha::Exceptions::Object::BadValue # found: DBIx::Class::Exception (DBIx::Class::Storage::DBI::_dbh_execute(): Incorrect datetime value: 'wrong_value' for column `koha_kohadev`.`borrowers`.`lastseen` at row 1 at /home/vagrant/kohaclone/Koha/Object.pm line 156 # ) # Looks like you failed 1 test of 1. # Failed test 'Bad value tests' # at t/db_dependent/Koha/Object.t line 363. # Looks like you failed 1 test of 16. Not on Jenkins It's the following exception's message that is not caught correctly by the regex: DBIx::Class::Storage::DBI::_dbh_execute(): Incorrect datetime value: 'wrong_value' for column `koha_kohadev`.`borrowers`.`lastseen` at row 1 at /home/vagrant/kohaclone/Koha/Object.pm line 156 Note the backticks. -- You are receiving this mail because: You are watching all bug changes.

1 47

[Bug 25492] New: Your Account Menu button does nothing on mobile devices
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '20

22 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25492 Bug ID: 25492 Summary: Your Account Menu button does nothing on mobile devices Change sponsored?: --- Product: Koha Version: 19.11 Hardware: Other OS: Other Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jyorio(a)equinoxinitiative.org QA Contact: testopia(a)bugs.koha-community.org Replicated with Koha 19.11.04 and 19.11.05 Steps to reproduce: 1) Bring up the OPAC on a mobile device with a smaller screen (e.g. cell phone) or using an emulator 2) Log into an account 3) Find the button labeled "Your account menu" 4) Click it. 5) Nothing happens. ****** I didn't see any errors in the browser console or in the Koha logs. I tested this with 18.11.05 and clicking the button expands the menu as you'd expect. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 22539] New: Fines charged on back-dated checkin when item has been renewed
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '20

22 Jun '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22539 Bug ID: 22539 Summary: Fines charged on back-dated checkin when item has been renewed Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- In a certain niche situation, a patron can end up with an unexpected fine due to renewing a book just prior to returning it. Here's the situation: - Patron has a book due on a Saturday and doesn't return it - On Sunday, the library is closed - Early Sunday morning, the fines cron generates an accruing fine on the item - Patron puts the item in the bookdrop on Sunday - Patron renews the item via the OPAC on Sunday - At renewal, the fine changes from FU to F - Monday morning, the item is checked in via bookdrop mode, which back-dates the checkin to Saturday According to the old_issues table, the item was checked in before any fine was charged, but the fine remains on the patron's account. If the patron had not renewed the item, the fine would have remained FU and would have been forgiven on checkin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50