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

[Bug 31051] New: Show patron's 'savings' on the OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31051 Bug ID: 31051 Summary: Show patron's 'savings' on the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org It would be cool to have a feature which would show patrons via the OPAC how much they've saved by using the library, instead of purchasing items themselves. -- You are receiving this mail because: You are watching all bug changes.

1 74

[Bug 35199] New: Fix error handling in http-client.js
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35199 Bug ID: 35199 Summary: Fix error handling in http-client.js Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34448 Coming from bug 34448. 386 // Submit the form, get 500 387 cy.intercept("POST", "/api/v1/erm/agreements", { 388 statusCode: 500, 389 error: "Something went wrong", 390 }); 391 cy.get("#agreements_add").contains("Submit").click(); 392 cy.get("main div[class='dialog alert']").contains( 393 "Something went wrong: SyntaxError: Unexpected end of JSON input" 394 ); This is totally wrong. We are now showing a JS error instead of the expected 500: internal server error! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34448 [Bug 34448] ERM should be able to display error messages coming from the API -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 35167] New: GET /items* broken if notforloan == 0
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35167 Bug ID: 35167 Summary: GET /items* broken if notforloan == 0 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com The Koha::Item->to_api method has this (modded for readability): $overrides->{effective_not_for_loan_status} = $self->notforloan ? $self->notforloan : $self->itemtype->notforloan; This is weird, because on the table definition, that column is defined as NOT NULL: `notforloan` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'authorized value defining why this item is not for loan (MARC21 952$7)', so, if the item has a value of '0', then it will look for the itemtype's default `notforloan` value, which can be (and most of the time is) NULL! I will provide a patch checking 'defined $self->notforloan' but it feels like adding `effective_not_for_loan_status` was a mistake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 35148] New: before_send_messages plugin hook does not pass the --where option
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35148 Bug ID: 35148 Summary: before_send_messages plugin hook does not pass the --where option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The before_send_messages plugin hook currently sends all the non-smtp related options with the exception of the --where option. This should be added. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 35072] New: Invalid usage of "& " in JavaScript intranet-tmpl script redirects
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35072 Bug ID: 35072 Summary: Invalid usage of "&" in JavaScript intranet-tmpl script redirects Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org There are several files under `koha-tmpl/intranet-tmpl/prog/js/**.js`, where `&` character in the URLs is incorrectly replaced with `&`. In practice, `&` should only ever be used a part of HTML elements, for example inside of <a href=""> link. Using it in JS redirects such as `window.location="addbiblio.pl?op=delete&biblionumber=` is incorrect! The `&` part is preserved like this by both the web browser and the web server. This creates several bugs, such as the one I've encountered and managed to trace back to this very issue. For example this makes you unable to delete a biblio record in admin interface AT ALL. To reproduce just install a fresh Koha installation, import a record and try to delete it. It would redirect you to the search.pl page, but nothing would happen. I traced the above to this: https://github.com/Koha-Community/Koha/blob/f27ed123be8ac1f0ecd76cd54ed9c2a… Which causes the variable `$biblionumber` to be null here: https://github.com/Koha-Community/Koha/blob/f27ed123be8ac1f0ecd76cd54ed9c2a… Which causes the `$frameworkcode` variable to be unpopulated here: https://github.com/Koha-Community/Koha/blob/f27ed123be8ac1f0ecd76cd54ed9c2a… Which causes the following warnings: ``` [2023/10/17 09:04:43] [WARN] Use of uninitialized value $frameworkcode in string eq at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 513. [2023/10/17 09:04:43] [WARN] Use of uninitialized value $frameworkcode in string eq at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 517. [2023/10/17 09:04:43] [WARN] Use of uninitialized value $frameworkcode in string eq at /usr/share/koha/intranet/cgi-bin/cataloguing/addbiblio.pl line 536. ``` I did a quick search, and found out that these files need to be corrected: * koha-tmpl/intranet-tmpl/prog/js/catalog.js * koha-tmpl/intranet-tmpl/prog/js/members-menu.js * koha-tmpl/intranet-tmpl/prog/js/holds.js * koha-tmpl/intranet-tmpl/prog/js/cart.js * koha-tmpl/intranet-tmpl/prog/js/ill-list-table.js * koha-tmpl/intranet-tmpl/prog/js/pages/results.js I ended up submitting it as bug, as it will probably be much faster to get submitted and approved by someone who already has a dev workflow set up to contribute the patch... Not sure if the severity I used is okay, but this prevents many features in the UI from working properly at all, so I think it is pretty important to fix this quickly. The random bugs/partial breakage this can cause can make hard-to-notice and hard-to-trace problems appear... -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 35069] New: Items to buy column on circ/reserveratios.pl does not sort properly
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35069 Bug ID: 35069 Summary: Items to buy column on circ/reserveratios.pl does not sort properly 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Make a lot of holds. 2. On some holds have a high enough holds/copies ratio so the "Items to buy column" has values greater than 10. 3. Sort by that column. Notice the copies with an "Items to buy" higher than 10 do not get sorted correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34983] New: Retranslating causes changes in locale_data.json
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34983 Bug ID: 34983 Summary: Retranslating causes changes in locale_data.json Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Actually, nothing may have changed. But the hash keys are processed in random order. We could force ordering them at a slightly slower rate. Advantage would be to see only changes when translations really changed. Actually, the performance changes that I saw were neglectible. The staff po file is converted in about 600-700 ms both ways. Sometimes the one is faster than the other even. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 34908] New: Sort item types alphabetically by description rather than code when adding a new empty record as an order to a basket
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34908 Bug ID: 34908 Summary: Sort item types alphabetically by description rather than code when adding a new empty record as an order to a basket Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Item types are sorted by the code rather than the description in the Item type dropdown that is used when adding a new empty record as an order to a basket. To reproduce: 1. Go to Koha administration -> Item types. Add a new item type "B" with the description "Test" so it will be obvious if it is sorted by the code "B" instead of the description "Test". 2. Go to Acquisitions. Add to a basket from a new empty record 3. In the Catalog details section, note the Item type dropdown. Confirm your "Test" item type, is showing near the top of the list, indicating it has been sorted based on the code "B" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 35321] New: Late orders link and page should be renamed
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35321 Bug ID: 35321 Summary: Late orders link and page should be renamed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In acquisition module, on the left menu, the link "late orders" opens this page : https://koha-univ-cotedazur.biblibre.fr/cgi-bin/koha/acqui/lateorders.pl The list contains all orders for which delivery is awaited, so "late order" is misleading. Maybe it should be labelled "Pending orders" or "Expected orders"? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34731] New: C4::Letters::SendQueuedMessages can be triggered with an undef message_id
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '23

13 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34731 Bug ID: 34731 Summary: C4::Letters::SendQueuedMessages can be triggered with an undef message_id Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I've discovered that sometimes C4::Letters::EnqueueLetter will return undef instead of a valid message id. In Koha::Patron::set_password we call C4::Letters::EnqueueLetter and assume a message_id exists which we pass to C4::Letters::SendQueuedMessages. Because message_id is undef, we then *process all pending messages*. This is very very bad considering libraries often have very specific time frames they wish to send message ( especially sms and phone ). In addition, this bypasses the before_send_messages hook. I have not been able to recreate on demand yet, but I think it is either random or caused by calls to the /api/v1/patrons/<patron_id>/password rest api endpoint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34