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

[Bug 33888] New: Overdue fines not displayed branchoverdues.pl error 500
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33888 Bug ID: 33888 Summary: Overdue fines not displayed branchoverdues.pl error 500 Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cacho(a)genac.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If there are no overdue items with fines, the report works, but if there are overdues with fines, they won't display, the script returns a 500 error, and the log records this: [Fri Jun 02 12:35:22.463020 2023] [cgi:error] [pid 8954] [client 192.168.1.1:47406] AH01215: Template process failed: undef error - : filter not found at /usr/share/koha/lib/C4/Templates.pm line 127.: /usr/share/koha/intranet/cgi-bin/circ/branchoverdues.pl, referer: http://bibliotecacho-intra.locales/cgi-bin/koha/circ/circulation-home.pl [Fri Jun 02 12:35:22.527939 2023] [cgi:error] [pid 8954] [client 192.168.1.1:47406] End of script output before headers: branchoverdues.pl, referer: http://bibliotecacho-intra.locales/cgi-bin/koha/circ/circulation-home.pl This happens for 23.05 too. I tested this with a new install, english only, from debian packages. Also happened when updating a couple of unrelated servers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 33885] New: Get HTTP 500 when retrieving orders created by a non-existent (deleted) user
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33885 Bug ID: 33885 Summary: Get HTTP 500 when retrieving orders created by a non-existent (deleted) user Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33293 Problem description: Occurs for orders where 'created_by' is NULL with the message in log: DBIC result _type isn't of the _type Borrower at /usr/share/koha/lib/Koha/Objects.pm line 463. This did not occur before in version 22.11 because there was no modal and the logic was different. Generally, according to the design, it is assumed that 'created_by' can be NULL, for example, due to a constraint that cleans it when the borrower record is deleted from the database. Steps to reproduce: 1. Create a superuser. 2. Add an order to the cart as a new user. 3. Delete the new user from the system. 4. Go to the orders section and select an order created by the non-existent user. 5. Click the "Get Order" button. Expected behavior: When attempting to retrieve an order created by a non-existent user, a confirmation pop-up window should appear for order retrieval. Actual behavior: Clicking the "Receive" button results in a JS alert with 'error 500 / The system is unable to process the request and returns an internal server error' message. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33293 [Bug 33293] Use template wrapper for tabs: Holds -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 22592] New: Elasticsearch - Support for index scan
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22592 Bug ID: 22592 Summary: Elasticsearch - Support for index scan Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ere.maijala(a)helsinki.fi Target Milestone: --- We can emulate index scan at least to some extent by using faceting with an include filter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[Bug 34141] New: OPAC Search Performance on Ubuntu Server
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '23

10 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34141 Bug ID: 34141 Summary: OPAC Search Performance on Ubuntu Server Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: amar(a)ourlib.in QA Contact: testopia(a)bugs.koha-community.org We are experiencing a performance issue with the OPAC search functionality on our server. Despite enabling memcached and Apache2 cache services, the OPAC search is extremely slow and consumes excessive CPU resources, leading to server downtime. Here are the details of our server: - Operating System: Ubuntu 20.04 LTS - CPU: 4 cores - RAM: 8GB - Storage: 200GB SSD When monitoring the server using the 'top' command, we observe that only a few OPAC search requests are being processed. However, these requests are utilizing nearly all of the available CPU resources, leaving no CPU capacity for other tasks and causing the server to go down. It's worth mentioning that we did not utilize the 'koha-common' command for the Koha installation and setup. Instead, we downloaded the Koha tar file and performed the installation using the 'perl Makefile.PL' command. We kindly request your assistance in improving the speed and performance of our server. Any suggestions or guidance on optimizing the OPAC search functionality would be greatly appreciated. Thank you in advance for your support. Please check detailed server log here : https://github.com/Londheamar/koha-issue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 29947] New: Show an estimated waiting time when placing hold in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29947 Bug ID: 29947 Summary: Show an estimated waiting time when placing hold in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Do some calculation based on number of holds and max loan period. Would have to take decreaseLoanHighHolds into account too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 17842] New: Broken diacritics on records exported as MARC from cart on reimport
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17842 Bug ID: 17842 Summary: Broken diacritics on records exported as MARC from cart on reimport Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I have experienced this problem for a while now in different versions, but I am not quite sure what's going wrong: - Add a records with diacritics, such as German umlauts äüö to your cart - Download the record from the cart in MARC - Import the record into Koha using the staged MARC import - Verify that the MARC preview doesn't work in the staged MARC import table - Verify that the umlauts didn't import correctly When using the 'import record' feature in Rancor, the diacritics also appear broken, fields containing diacritics get cut off and other oddities happen. -- You are receiving this mail because: You are watching all bug changes.

1 63

[Bug 31291] New: Batch import of records from ISBN list
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31291 Bug ID: 31291 Summary: Batch import of records from ISBN list Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Many libraries are moving away from the big vendors (and their bulk record files for import) and are looking for a way to import batches of records. For instance, if I order 20 items from Amazon, etc, I have to import each record one by one. It would be helpful to have a tool where I could enter a list of ISBNs, select one of my z39.50 targets, and import the records that are found. The function would need to have some sort of matching rules that could be applied, and have the results in a grouped set like it is with staged record batches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30342] New: Incorrect check for outstanding holds on order receive page
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30342 Bug ID: 30342 Summary: Incorrect check for outstanding holds on order receive page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 20212 On the "Receive orders" page (acqui/parcel.pl?invoiceid=X) there is a check for outstanding holds which is supposed to be used to disable cancellation if there are any holds. This isn't working: Holds to not block cancellation. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20212 [Bug 20212] Improve performance of acquisitions receive page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28743] New: With IndependentBranches block changes to biblio records shared with other libraries
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28743 Bug ID: 28743 Summary: With IndependentBranches block changes to biblio records shared with other libraries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.hafen(a)washk12.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 28323] New: Invalid record in sample data leading to error when displaying
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '23

08 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28323 Bug ID: 28323 Summary: Invalid record in sample data leading to error when displaying Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org Strk̆v̜elser illustreret af Jean Anderson dansk udgave ved Lis Engel [overst̆telse ved Jesper Langer] staff://cgi-bin/koha/catalogue/detail.pl?biblionumber=369 opac://cgi-bin/koha/opac-detail.pl?biblionumber=369 ========= error ============ Invalid data, cannot decode metadata object (biblio_metadata.id=368, biblionumber=369, format=marcxml, schema=MARC21, decoding_error=':8: parser error : PCDATA invalid Char value 31 <controlfield tag="001">00aD000015937</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ============ Here is some analysis by Caroline ============ I can't find the exact problem with record 369, but it's definitely problematic, even MarcEdit won't open it I can view it with a command line tool that I have Problem record : https://snipboard.io/paTtIK.jpg the error messages seem to point to the control fields 001, 004 (which doesn't exist in MARC21 afaik), and 008 Compared with a healthy record : https://snipboard.io/XFZ5VN.jpg In fact, there are a couple more fields in the problem record that dont exist in MARC21 : 021 (should probably be 020), 245$d (should probably be 245$c?), 245$f should be dates The fact that indicators are all 00 is also wierd... anywho, I think there is probably a character at the beginning of the record that is messing up everything else tuxayo: does this look like a legitimate record to have in sample data? Because real world data can be weird ^^ tuxayo: Or is this worthless and should be removed from sample data? caroline: I think it should be removed.... I mean it's just sample data and this one is clearly a problem Unless it was there for a specific purpose like you suggested it causes problem when searching for danish documents too :/ Advanced search > Language Danish > Search > Error ====== issue with search of Danish records ======= - OPAC - advanced search - Language dropdown => Dansk - search - error Actually it's just that it redirects to the record page -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6