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

[Bug 43193] New: Non-numeric offset or creep values on printer profiles cause a 500 error
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '26

29 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43193 Bug ID: 43193 Summary: Non-numeric offset or creep values on printer profiles cause a 500 error Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger(a)veritassuperaitsolutions.com Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The offset and creep fields on both printer profile editors are plain text inputs whose values are passed straight to the database: labels/label-edit-profile.pl patroncards/edit-profile.pl printers_profile.offset_horz, offset_vert, creep_horz and creep_vert are float NOT NULL. Typing ordinary non-numeric text into any of the four fields -- "abc", or the European decimal form "1,5" -- sends that string to the column. On an installation running STRICT_TRANS_TABLES the insert or update raises a database exception, which surfaces to the user as a bare 500 error page. Without strict modes the value is silently coerced to 0 with a warning, so the profile saves with an offset the librarian did not ask for. No tampering is needed; the inputs are type="text" and accept anything typed into them. To reproduce (strict SQL modes enabled): 1. Cataloging > Label creator > Manage > Printer profiles > New profile (or Tools > Patron card creator > Manage > Printer profiles > New profile) 2. Enter a printer name and paper bin. 3. Type "abc" into the horizontal offset. 4. Save. -- a 500 error page is returned rather than a validation message Bug 21052 made the related empty-string case safe: a cleared offset now coerces to 0 in both editors, and that patch also added handling so a duplicate profile no longer 500s. Non-empty non-numeric input was left out of scope there because it is a different defect class -- it wants server-side numeric validation (and probably type="number" or inputmode on the four inputs, in both editors), rather than a default for a missing value. Found during multi-model review of the bug 21052 patch. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 43191] New: Clean up printer profiles saved with a blank printer name or paper bin
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43191 Bug ID: 43191 Summary: Clean up printer profiles saved with a blank printer name or paper bin Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger(a)veritassuperaitsolutions.com Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Bug 21052 allowed a printer profile to be saved with a blank printer name or paper bin: the editors did not validate the two fields, so a blank was stored as an empty string. Any site that hit that bug has at least one such row in printers_profile. The patch on bug 21052 stops new blank rows being created and makes an existing blank row repairable in place (a blank stored value renders as an editable input rather than read-only), so no site is stuck. It deliberately ships no data fix, because repairing existing rows is a separate concern from the code defect and wants its own test plan. What is left to decide here: - Whether to repair or remove the affected rows. A blank profile cannot be meaningfully applied to a template, so removal is plausible, but a row may be referenced by printers_profile.template_id associations a site still wants. - Whether an atomicupdate should act at all, or simply report the affected rows so the library can choose. To find affected rows: SELECT profile_id, printer_name, paper_bin, creator FROM printers_profile WHERE TRIM(printer_name) = '' OR TRIM(paper_bin) = ''; Depends on bug 21052 -- the validation fix should land first so that no new blank rows appear while this is being decided. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41503] New: Rename OPAC > Your account sections in the manual
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41503 Bug ID: 41503 Summary: Rename OPAC > Your account sections in the manual Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Since 22.11 and bug 31672, the tabs visible by a user when logged in the OPAC have been renamed. Instead of "Your summary", the tab is now called "Summary"; "Your personal details" is now "Personal details"; etc. The Koha Manual page at https://koha-community.org/manual/latest/en/html/opac.html#your-account should be updated with the current names of the tabs (headers, text and screenshots). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41645] New: Make self-checkout use responsive CSS
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41645 Bug ID: 41645 Summary: Make self-checkout use responsive CSS Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 20168 added the the directive '@import "responsive";' to the bottom of ./koha-tmpl/opac-tmpl/bootstrap/css/src/sco.scss, so we've had media queries and responsive CSS in the sco.css file for about 5 years now, but... they don't actually work. And it's because this one line of HTML is missing from koha-tmpl/opac-tmpl/bootstrap/en/modules/sco/sco-main.tt: <meta name="viewport" content="width=device-width, initial-scale=1"> Once that line is added, the CSS media queries start to work. Of course, there's a bit more that needs to be done on top of that. The input for the barcode is too narrow and misplaced, the Checkouts datatable runs off the page. But those are manageable problems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 40006] New: Upgrading install.pl shows code vs HTML
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40006 Bug ID: 40006 Summary: Upgrading install.pl shows code vs HTML Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: ssammons(a)npelem.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 182806 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182806&action=e… Screen segment of Chrome browser showing code vs HTML output When upgrading from version 23 (sorry I did it by accident, so I didn't not the subversion) after entering the credentials from the .xml file and proceeding to update the database, install.pl shows code above the HTML code, and I believe this breaks the HTML structure, viewing the page source it looked the same as the page, less in Chrome it puts line numbers on the left. Here is what appears about the HTML tags. 0E0 Status: 200 OK Set-Cookie: CGISESSID=af07240f027e658abfa81c3155df289f; path=/; HttpOnly; SameSite=Lax Date: Tue, 27 May 2025 19:03:47 GMT Cache-control: no-cache Content-script-type: text/javascript Content-style-type: text/css Pragma: no-cache X-frame-options: SAMEORIGIN Content-Type: text/html; charset=UTF-8 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 42838] New: Update some cataloging pages to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42838 Bug ID: 42838 Summary: Update some cataloging pages to use grid layout for forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39780 Target Milestone: --- This patch will update the following templates to use grid layout for the forms: - Cataloging -> Z39.50 search - Cataloging -> Merge - Authorities -> Z39.50 search - Authorities -> Merge Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 12278] Total amount of each invoice should be displayed in invoices page (parcels.pl)
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12278 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Passed QA --- Comment #9 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Putting back to PQA based on movement on dependency -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42840] New: Update some patron account and POS pages to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42840 Bug ID: 42840 Summary: Update some patron account and POS pages to use grid layout for forms Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 39780 Target Milestone: --- This patch will update the following templates to use grid layout for the forms: - includes/transaction_types.inc - members/boraccount.tt - members/mancredit.tt - members/maninvoice.tt - members/paycollect.tt - pos/pay.tt - pos/register.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 28806] New: Labels exported as PDF create zero sized PDF files.
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28806 Bug ID: 28806 Summary: Labels exported as PDF create zero sized PDF files. Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: egpetridis(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org In my first tries to create biblio labels, I see that export to PDF creates zero sized PDF files, in both individual/single and batch modes. Coult it be due to non-latin characters (Greek) appearing in the label contents? Export to CSV does produce files with the expected number of rows, albeit with non-usable characters. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 43189] New: Action logs API returns 500 when filtering by date
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '26

28 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43189 Bug ID: 43189 Summary: Action logs API returns 500 when filtering by date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Target Milestone: --- When using Tools → Log viewer, filtering action logs by a date range can cause the Action Logs API to return a 500 Internal Server Error. On a partner site running 25.11.06, the API request fails with: DBIx::Class::Exception: DBIx::Class::Storage::DBI::_prepare_sth(): DBI Exception: DBD::mysql::db prepare_cached failed: Column 'timestamp' in WHERE is ambiguous From investigating the generated API filters, the date filter is currently built using the unqualified field: filters.timestamp = { ">=": params.datefrom + "T00:00:00Z", "<=": params.dateto + "T23:59:59Z", }; whereas the query already qualifies the sort column as me.timestamp. Qualifying the filter in the same way appears to resolve the ambiguity: filters["me.timestamp"] = { ">=": params.datefrom + "T00:00:00Z", "<=": params.dateto + "T23:59:59Z", }; I have been able to reproduce this consistently on a partner site running 25.11.06, but I have not yet found a reliable way to reproduce it on a clean main installation. It appears to depend on the generated query and/or data that causes additional joins, resulting in the ambiguous timestamp column. More eyes on this would be great! Thank you! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0