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

[Bug 32575] New: gather_print_notices.pl sends HTML file as body of email
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32575 Bug ID: 32575 Summary: gather_print_notices.pl sends HTML file as body of email Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org gather_print_notices.pl can send print notices to the library, as an HTML file attached to an email. At least some libraries report that the HTML does not come as an attached file, but as the body of the email. This breaks printing the notices properly. I am not sure if this is a problem with the emails generated by gather_print_notices.pl or with the email clients (or other software) used by the libraries that have this problem. A quick solution has been to add some body text to the emails generated by gather_print_notices.pl: 299 my $email = Koha::Email->create( 300 { 301 from => $from, 302 to => $to, 303 subject => 'Print notices for ' . $today_syspref, 304 text_body => 'See attached file.', # <==== Added this 305 } 306 ); This seems to force the attachment to be seen as an attachment, and not as the body of the email. In the headers of the emails sent by the standard gather_print_notices.pl I have seen this: Content-Transfer-Encoding: base64 Content-Type: text/html; charset=iso-8859-1 PCFET0NU... [lots of base64] When I have added some body text it looks more like this: Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="16633311691.0Ab5.3555417" --16633311691.0Ab5.3555417 Date: Fri, 16 Sep 2022 14:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable See attached file. --16633311691.0Ab5.3555417 Date: Fri, 16 Sep 2022 14:26:09 +0200 MIME-Version: 1.0 Content-Type: text/html; name="notices_all-2022-09-16-KOHA.html" Content-Disposition: attachment; filename="notices_all-2022-09-16-KOHA.html" Content-Transfer-Encoding: base64 PCFET0... [lots of base64] So unless something is changed on the way from Koha to the mail client, it looks like gather_print_notices.pl sends the HTML from the document as the body of the email. Not sure if this is a problem in Koha::Email->create that should be fixed there, or if it makes sense to just add some default text to the email, to fix the problem in the least obtrusive way? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 37814] New: Wrong use of __() in .tt files
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37814 Bug ID: 37814 Summary: Wrong use of __() in .tt files Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org __() does not work in .tt files (only .js files) _() must be used instead The 4 occurrences returned here are wrong. % git grep '__(' **/*.tt koha-tmpl/intranet-tmpl/prog/en/modules/members/alert-subscriptions.tt: return confirmDelete(__("Are you sure you want to unsubscribe %s from email alerts for %s?").format(patron, title)); koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt: node.addClass("collapsed").removeClass("expanded").attr("title", __("Click to expand this section") ); koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt: node.addClass("expanded").removeClass("collapsed").attr("title", __("Click to collapse this section") ); koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-alert-subscriptions.tt: return confirmDelete(__("Are you sure you want to unsubscribe %s from email alerts for %s?").format(patron, title)); -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 37528] New: Using borrowerRelationship while guarantor relationship is unchecked from BorrowerMandatoryField results in error
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37528 Bug ID: 37528 Summary: Using borrowerRelationship while guarantor relationship is unchecked from BorrowerMandatoryField results in error Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: katariina.pohto(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Before 24.05 having values in borrowerRelationship made the guarantor relationship field required in patron page. Now one needs to check the relationship option from BorrowerMandatoryField settings. If borrower relationships are used but the relationship is not set up as required field, it is possible to save a patron with the empty option from gurantor relationship drop down selector. This will result in an internal service error. Despite the error, the new patron will be saved, but the guarantor information is lost in the process, as it wasn't valid. To replicate: Have at least one option in borrowerRelationship Have the relationship field unchecked from BorrowerMandatoryFields 1. Create or select an existing patron in category that can be a guarantee. 2. Select a guarantor but leave the relationship blank 3. Fill in the other required information if not present yet. 4. Try to save the patron. 5. Notice an error page. 6. Check the patron and note that the new patron or changes to existing one were saved without the new guarantor information. Also, I'd like to add that when adding a new guarantee for an existing patron, the hint text for required field doesn't show correctly with the mandatory field setting. It will show 'required field' when it's UNchecked from mandatory fields, and doesn't show it when it's checked. When creating a new patron from scratch or editing an existing guarantee patron, the 'required field' text works correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 36494] New: Flatpickr error on checkout pages if the patron is blocked from checking out
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36494 Bug ID: 36494 Summary: Flatpickr error on checkout pages if the patron is blocked from checking out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 18885 The change made by Bug 18885 can fail if the patron is restricted or expired. In that situation, the #duedatespec input doesn't exist, and trying to apply a Flatpickr configuration to it causes an error in the console: Uncaught TypeError: can't access property "_flatpickr", document.querySelector(...) is null Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18885 [Bug 18885] When 'on-site checkout' was used, the 'Specify due date' should be emptied for next checkout unless OnSiteCheckoutAutoCheck -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 35483] New: Restore item level to record level hold switch in hold table
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35483 Bug ID: 35483 Summary: Restore item level to record level hold switch in hold table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 33575 commit [1] has reverted hold level switch feature added in Bug 31692 commit [2] to holds table. Switching item level holds to record level holds no longer works in the table. Let's restore the feature in this Bug. [1] https://github.com/Koha-Community/Koha/commit/c649f73d029b406a6bad80c31b838… [2] https://github.com/Koha-Community/Koha/commit/b0f49d5dafa4e2dcc05e1e85c13cd… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 36461] New: Advanced editor should disable RequireJS timeout with waitSeconds: 0
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36461 Bug ID: 36461 Summary: Advanced editor should disable RequireJS timeout with waitSeconds: 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We currently set waitSeconds: 30 for RequireJS in the advanced editor, which as bug 35799 says just causes loading of the editor to hang forever if loading any required part (which practially speaking means loading svc/cataloguing/framework) takes more than 30 seconds. As jrburke says in https://github.com/requirejs/requirejs/issues/787 waitSeconds exists to show developers why things aren't working when they try to require something that 404s, and to allow error handling in old versions of IE. But since we aren't doing any error handling, we'd be better off setting it to 0, which disables the timeout, and just letting things load no matter how long they take. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 27363] New: Restore temporary selection of Z39.50 targets throughout multiple searches
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27363 Bug ID: 27363 Summary: Restore temporary selection of Z39.50 targets throughout multiple searches Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Prior to 20.05.06, when using Z39.50 in the Advanced Cataloging Editor, servers that were selected each time a new Z39.50 search was done would be retained throughout multiple searches. This is no longer the case. It would be helpful if that behavior was restored. We have preselected servers which persist for all searches. As we catalog we add some additional servers that would be retained for a short period of time until we decided we no longer needed them. For instance, we may be cataloging Spanish and we could check a server that could be used for several bibs but it wasn't a server that we wanted to be a preselected server. Now that a newly checked server is not retained in the short term we have to check it again for every search which is much less efficient. We could go into Admin and make it a preselected search for the short duration we plan to use it and then go back into Admin to uncheck it when done but that is also not efficient. It would be so much more efficient to be able to check a new server, have it retained, and then uncheck it when done. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 37724] Remove Koha version number from public generator metadata
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37724 Wainui Witika-Park <wainuiwitikapark(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldoldstable |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36998] New: 'Issue refund' modal on registers.pl can mistakenly display amount from previously clicked on transaction
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36998 Bug ID: 36998 Summary: 'Issue refund' modal on registers.pl can mistakenly display amount from previously clicked on transaction Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: martin.renvoize(a)ptfs-europe.com CC: martin.renvoize(a)ptfs-europe.com In the POS module, the 'Issue refund' modal on registers.pl mistakenly carries forward the amount paid to subsequent modals. Steps to reproduce: -Have the Point of Sale module enabled, a cash register defined and multiple debit types defined -Make multiple sales -View the transaction history for your sales on register.pl -Click on the 'Issue refund' button for one of the sales -Notice that the 'amount paid' displays the amount of the sale -Realize that you selected the wrong transaction for the refund -Find the actual transaction you want to refund and click on the 'Issue refund' button -Notice that the amount listed in the 'amount paid' area is the amount from the first refund you attempted to make, not the amount for the transaction now being handled In the attached screenshots one shows a payment of 3.80. That turned out to be the wrong transaction. Staff then located the correct transaction to be refunded. The amount shows 3.80 (carried over from the previous transaction that was clicked on) but the amount of the original payment was actually 7.40. Not only is the amount of 3.80 incorrect but it is especially confusing since it looks as if you would be refunding more than the original payment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 36196] New: Handling NULL data in ajax calls for cities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36196 Bug ID: 36196 Summary: Handling NULL data in ajax calls for cities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello all, Just a simple patch here, I had the case recently, if a data is null in the cities table, the datatable won't handle the data well and will load indefinitely. I've added a condition so that it can be displayed despite NULL data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26