April 2026 - Koha-bugs - lists.koha-community.org

[Bug 36025] New: Extended attributes clause added to patron search query even when there are no searchable attributes
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36025 Bug ID: 36025 Summary: Extended attributes clause added to patron search query even when there are no searchable attributes Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In bug 34519 there is a commit labelled "ensure we always have an array": - [% SET extended_attribute_types = ExtendedAttributeTypes.codes( staff_searchable => 1 ) %] + [% SET extended_attribute_types = [ ExtendedAttributeTypes.codes( staff_searchable => 1 ) ] %] Somehow this expands into an array containing the empty string as an element if no attributes are searchable by default. This is likely a bug in DBIx::Class. It would be better to add the workaround for this in the ExtendedAtributeTypes template plugin. The get_column method of ResultSet returns values of type ResultSetColumn according to the documentation. But in reality it does not. It returns an array. So we must rely on a bug already by using this method. Consistently using it in list context might be helpful as a workaround. sub codes { my ( $self, $params ) = @_; my @codes = Koha::Patron::Attribute::Types->search($params)->get_column('code'); return \@codes; } The consequence is that a clause for extended attributes is added to the patron search query. This is significantly slower than not having such a clause, due to some other issues with DBIx::Class. (Se bug 33554 and bug 35361.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 38349] New: Fix style of sidebar form submit button on tags review page
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38349 Bug ID: 38349 Summary: Fix style of sidebar form submit button on tags review page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org On the tags review page the style of the submit button is incorrect. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 38459] New: Cities dropdown should work for quick add form as well
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38459 Bug ID: 38459 Summary: Cities dropdown should work for quick add form as well Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the cities dropdown does not work in the patron quick add, in fact city doesn't seem to work due to the way the selector/id are formed To recreate: 1 - Administratoin->Cities and towns 2 - Define several cities 3 - http://localhost:8081/cgi-bin/koha/admin/preferences.pl?op=search&searchfie… 4 - Select city,state, zipcode and some other fields 5 - Patrons->Quick add new patron 6 - Note city field/dropdown does not show -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 38617] New: Fix warning about auto increment and biblioitems
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38617 Bug ID: 38617 Summary: Fix warning about auto increment and biblioitems Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Bug 35033 added a check for auto increment problems related to biblioitems. The code looks like this: my $biblioitems = $dbh->selectall_arrayref( q|select bi.biblioitemnumber from biblioitems bi join deletedbiblioitems dbi on bi.biblionumber=dbi.biblionumber|, { Slice => {} } ); It compares biblioitems and deletedbiblioitems, which makes sense. But the template that displays the results look like this: [% IF ai_biblioitems %] <h4>Bibliographic records</h4> <p>The following IDs exist in both tables [% "biblio" | $HtmlTags tag="strong" %] and [% "deletedbiblioitems" | $HtmlTags tag="strong" %]:</p> <p> [% FOR b IN ai_biblioitems %] [% b.biblioitemnumber | html %] [% UNLESS loop.last %], [% END %] [% END %] </p> [% END %] The problem is this: The following IDs exist in both tables [% "biblio" | $HtmlTags tag="strong" %] and [% "deletedbiblioitems" | $HtmlTags tag="strong" %] It says "biblio and deletedbiblioitems", when it should say "biblioitems and deletedbiblioitems". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 38711] New: Wrong font-weight in tables during printing from STAFF interface
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38711 Bug ID: 38711 Summary: Wrong font-weight in tables during printing from STAFF interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com While printing a page from the Koha STAFF interface all last columns of tables use **bold** font while on screen they use normal font. This can be seen e.g. when running reports to feed a notice. This happens due to the following CSS defined for _print_: ``` td:last-child, th:last-child { background-color: #E9E9E9; border-bottom: 1px solid #CCCCCC; border-left: 0; border-right: 0; border-top: 0; font-size: 14px; font-weight: bold; padding: 5px 5px 5px 5px; } ``` This assigns `font-weight: bold` to all `last-child`s of `td`. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 36114] New: Port default TRANSFERSLIP notice to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36114 Bug ID: 36114 Summary: Port default TRANSFERSLIP notice to Template Toolkit syntax Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 38748] New: Branch name is missing in Return to Home transfer modal
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38748 Bug ID: 38748 Summary: Branch name is missing in Return to Home transfer modal Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 38753] New: Missing table cells breaks OPAC charges table
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38753 Bug ID: 38753 Summary: Missing table cells breaks OPAC charges table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW 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 There are a couple of missing instances of the empty '<td></td>' required by DataTables to make the table responsive. The table header/table cell mismatch breaks the DataTable behavior. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 38377] New: Wrong Turkish translation in renewal part
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38377 Bug ID: 38377 Summary: Wrong Turkish translation in renewal part Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: angelic(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com In renewal part there is a missunderstanding. Let me explain with an example. The sentence in English: "2 of 3 renewals remaining" is translated as "2 uzatma hakkınızdan 3 tane kaldı" in Turkish. This is wrong. Right Turkish translation must be like this : "3 uzatma hakkınızdan 2 tane kaldı" This information can be seen in (with a user having renewals): cgi-bin/koha/opac-user.pl page of user. cgi-bin/koha/circ/circulation.pl?borrowernumber=xxxx -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41120] New: Click on New data provider breaks functionality
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '26

20 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41120 Bug ID: 41120 Summary: Click on New data provider breaks functionality Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk This seems to be a regression bug as in 24.11. this feature is still working. To recreate: - in ERM add a data provider (/cgi-bin/koha/erm/eusage/usage_data_providers) - dummy data should be sufficient - on the new data provider overview click Close on the bottom to return to the data providers list. - open web development tools (F12 on Firefox) - click New data provider and see the error on the console. The reasons seems to be, that the add form gathers an erm_usage_data_provider_id from an older route in from.value.params.erm_usage_data_provider_id -- You are receiving this mail because: You are watching all bug changes.

1 17