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

[Bug 36475] New: members/summary-print.pl tables cannot be column configured
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36475 Bug ID: 36475 Summary: members/summary-print.pl tables cannot be column configured Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com To recreate: 1. Have a patron with some checkouts and some holds. 2. Go to Table settings > Circulation > print_summary and mark some of the columns as hidden. 3. Go to the patron account and click Print > Print summary 4. The hidden columns still appear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 38041] New: Not all self checkout errors behave the same
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38041 Bug ID: 38041 Summary: Not all self checkout errors behave the same Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For example: 1. Enable SCO and go to the SCO module 2. Attempt to checkout a non-existent barcode. 3. See the error that appears, nothing else. 4. Attempt to checkout something that is already checked out. 5. The error is much the same but you still see all parts of the SCO module. This is a problem for some libraries attempting smooth user experience for SCO users. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 37167] New: Fix mapping call number searches to Z39.50
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37167 Bug ID: 37167 Summary: Fix mapping call number searches to Z39.50 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org If you do an advanced search for Call number, your search will be for &idx=callnum, but the code in catalogue/search.pl that creates $z3950par to pass to z3950_search_args to eventually fill the form if you use the Z39.50/SRU Search button in your search results thinks that the index for callnum searches is still the one it was 15 years ago, lcn,phr, so instead of getting your search term filled in the "Dewey:" field (which isn't, it's a generic call number search), you get it in the "Title:" field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 37158] New: OPAC recalls history table not responsive
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37158 Bug ID: 37158 Summary: OPAC recalls history table not responsive Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 32341 There are some errors in the markup of the OPAC's recalls history page which is preventing the DataTable from behaving responsively. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32341 [Bug 32341] Some OPAC tables are not displayed well in mobile mode -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 37057] New: OPACShowUnusedAuthorities displays unused authorities regardless
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37057 Bug ID: 37057 Summary: OPACShowUnusedAuthorities displays unused authorities regardless Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To replicate: 1. Create a topic term authority "Example" 2. Duplicate that authority so there are two 3. Find a record and add the topical term "Example" 4. Link the topical term in the record to one of the two Example authorities. 5. Set OPACShowUnusedAuthorities to show. 6. Ensure OpacAuthorities is set to Allow. 7. Search Authorities in the OPAC for "Example" A list should be returned with Example listed twice. One of the authorities should display it is linked to a record and one should be "0" for no link. 8. Change OPACShowUnusedAuthorities to don't show 9. Refresh the page and repeat the authority search for "Example" See that the search results are identical. The Example result with no linked records still displays. I would have expected it to not display, unless there is some other preference or option that needs to be set. -- You are receiving this mail because: You are watching all bug changes.

1 17

[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