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

[Bug 21670] New: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21670 Bug ID: 21670 Summary: t/db_dependent/Plugins.t is failing randomly on Jenkins (U18) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor 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 On run #72, Koha_Master_U18 failed: koha_1 | Could not unlink /tmp/xRRc7ht/Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm.pm: No such file or directory at /kohadevbox/koha/Koha/Plugins/Handler.pm line 105. koha_1 | koha_1 | # Failed test 'Koha::Plugins::Handler::delete works correctly.' koha_1 | # at t/db_dependent/Plugins.t line 127. koha_1 | # Looks like you failed 1 test of 39. koha_1 | [15:24:05] t/db_dependent/Plugins.t ................................................ koha_1 | Dubious, test returned 1 (wstat 256, 0x100) koha_1 | Failed 1/39 subtests We requested another run and it passes (#73), same node (Docker_3) -- You are receiving this mail because: You are watching all bug changes.

1 25

[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 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 25387] New: Avoid merge different type of authorities
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25387 Bug ID: 25387 Summary: Avoid merge different type of authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When a librarian tries to merge two differents authorities for exampletopic_authority with geogrpahic_authority (Turkey) it deletes one of the authority and all the tags associated for example merging Turkey(topic) with Turkey(geographic) the result is all 650$aTurkey dissapear We should add a lock to avoid merge two different authorities... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 47

[Bug 29539] New: UNIMARCslimUtils.xsl
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29539 Bug ID: 29539 Summary: UNIMARCslimUtils.xsl Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: rafael.antonio(a)sapo.pt QA Contact: testopia(a)bugs.koha-community.org When it hapens UNIMARC record to have $9 after $a on biblio_metadata record like <datafield tag="606" ind1=" " ind2=" "> <subfield code="a">Portugal</subfield> <subfield code="9">12005</subfield> </datafield> OPAC details display the authority number and not the term. If we change record for <datafield tag="606" ind1=" " ind2=" "> <subfield code="9">12005</subfield> <subfield code="a">Portugal</subfield> </datafield> it display the term. Is it a bug? The only piece of XSLT code I see for such reason is at UNIMARCslimUtils.xsl file <xsl:choose> <xsl:when test="marc:subfield[@code=9]"> Any comment? -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 30230] New: Search for patrons in checkout should not require edit_borrowers permission
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30230 Bug ID: 30230 Summary: Search for patrons in checkout should not require edit_borrowers permission 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 15812 made searching for patrons for checkout use the regular patron search. This resulted in a significant change in behavior for users who have _circulate_ permissions but not _edit_borrowers_. Previously, a user with these permissions could enter a partial name, be taken to a list of search results, and select the patron they desire. Following bug 15812, a user with these permissions will hit a "You do not have permissions" block when attempting to search for a partial patron name. One can allow the search by adding _edit_borrowers_ permission, but that also grants the ability to create and edit patrons. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 119

[Bug 33563] New: Enable compatibility with Elasticsearch secure mode
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33563 Bug ID: 33563 Summary: Enable compatibility with Elasticsearch secure mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi friends, Koha should support authenticated access to Elasticsearch, at the very minimum https://www.elastic.co/guide/en/elasticsearch/reference/current/http-client… and https://www.elastic.co/guide/en/elasticsearch/reference/current/token-authe… We'd need a place to stash our ES configuration information much like we used to for Zebra. koha-conf.xml is probably fine? Obviously open to discussion from the way smarter people here - this is only to get the discussion started, as Elasticsearch will start creating egregious scary logs for every connection complaining about security, starting with version 7. Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 33455] New: Heading on 'update password' page it too big
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33455 Bug ID: 33455 Summary: Heading on 'update password' page it too big Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Staff interface 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 The h1 heading on the change password page is too big and should be outside of the legend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 26176] New: AutoLocation is badly named
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26176 Bug ID: 26176 Summary: AutoLocation is badly named 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org As far as I can tell AutoLocation isn't about koha picking a library branch automatically from your login IP address as much as it's a security feature to prevent you from logging into another branch from outside an IP range. As such, I feel the preference is either misnamed, or the description is incorrect.. either way it needs some clarification adding. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 61

[Bug 16567] New: RSS feeds show issues in W3C validator and can't be read by some aggregators (Chimpfeedr, feedbucket)
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16567 Bug ID: 16567 Summary: RSS feeds show issues in W3C validator and can't be read by some aggregators (Chimpfeedr, feedbucket) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We are seeing issues with some RSS aggregators refusing to load koha rss links, there are errors when checked in the W3C validator: https://validator.w3.org/feed/check.cgi -- You are receiving this mail because: You are watching all bug changes.

1 23