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

[Bug 27691] New: allow HTML in Notes output on guided_reports_start.tt
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27691 Bug ID: 27691 Summary: allow HTML in Notes output on guided_reports_start.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some reports have a long and detailed notes section pertaining to a given report. With the html filter it can be very difficult to parse out those notes. Is there any reason we cannot use a $raw filter in this situation? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 41006] New: Shelving location style changed in many places since Bug 40606
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41006 Bug ID: 41006 Summary: Shelving location style changed in many places since Bug 40606 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Shelving location style changed in many places since Bug 40606 See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40606#c9 -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 37666] New: Make additional fields available via Template Toolkit in notices
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37666 Bug ID: 37666 Summary: Make additional fields available via Template Toolkit in notices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It seems that is not possible today (or in a complex way?) to display in notices information stored in additional fields defined in admin/additional-fields.pl It could be nice to add this feature, in the same spirit as https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30657 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41499] New: Using the OPAC - Bibliographic record section improvements
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41499 Bug ID: 41499 Summary: Using the OPAC - Bibliographic record section improvements Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de The bibliographic section of using the OPAC could do with some improvements (https://koha-community.org/manual/latest/en/html/opac.html#bibliographic-re…) 1. Use one image of a record, instead of lots of images with circles highlighting elements. Then: - Use numbers/callouts to highlight the different elements - Use a table, definition list, or headings to describe each of these 2. There are a lot of options in the sidebar for what you can do, such as place a hold, place a recall, save a record, send to device, and so on: - Similar to the overall record description, use a table, definition list, or headings to describe each of these - In addition, link to the system preferences that turn these on or off (and the ones where you currently have to use JavaScript or CSS to hide them) Some challenges: 1. Adding numbers/callouts to the image, with the automated screen capture. 2. Finding a good example record that is reasonably complete and shows all the main elements for a record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37370] opac-export.pl can be used even if exporting disabled
by bugzilla-daemon＠bugs.koha-community.org 29 Dec '25

29 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37370 --- Comment #8 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Martin Renvoize (ashimema) from comment #7) > This breaks Zotero integration as the Zotero browser extension expects to be > able to call utf8 as a format. > > We find libraries don't want to visually show utf8 in the export menu, but > do want Zotero to work. Do we have a separate bug for that yet? At least we could add a hint to the system preference maybe. Or allow to access the format, but don't show it? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41342] New: Add a system preference to allow/disallow purchase suggestions on existing records
by bugzilla-daemon＠bugs.koha-community.org 28 Dec '25

28 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41342 Bug ID: 41342 Summary: Add a system preference to allow/disallow purchase suggestions on existing records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is a comment I *always* get during training and testing, libraries want a way to remove the "Suggest for purchase" link in a detailed record on the OPAC. I think the only way to disable it right now is by CSS or JS, but I feel like this is more of a "bandaid" solution because there is no system preference. And CSS and JS changes like this always risk breaking on upgrades (at least, that's my experience). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40918] New: Invoice Adjustment Reason always "No reason" even if report shows a saved reason
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40918 Bug ID: 40918 Summary: Invoice Adjustment Reason always "No reason" even if report shows a saved reason Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Go to Acquisition. 2. Create a vendor. 3. Click "Receive Shipment" 4. Enter an invoice number and save. 5. Go to Administration->Authorized Values->Add A Category 6. Name it ADJ_REASON 7. Put in 2 options 8. Go to invoices in Aqusition 9. Add an adjustment (enter an amount and select a reason, then save) 10. The reason is set to "no reason" 11. Go to reports 12. new sql report select * from aqinvoice_adjustments 13. Run the report and see your reason is saved. 14. go back to the invoice and click save adjustments 15. run the report again, see there's no longer a reason. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40292] New: SQL syntax error when upgrading to 25.05 on MariaDB 10.3, RENAME COLUMN unsupported
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40292 Bug ID: 40292 Summary: SQL syntax error when upgrading to 25.05 on MariaDB 10.3, RENAME COLUMN unsupported Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Got this report on Mattermost for 25.05: Configurando koha-common (25.05.01-1) ... Upgrading database schema for biblio Upgrade to 24.12.00.042 [07:56:03]: Bug 39838 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39838) - Rename alias_id -> vendor_alias_id ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'COLUMN alias_id TO vendor_alias_id' at line 1 at /usr/share/koha/lib/C4/Installer.pm line 825 After investigation and confirmation, the usage of RENAME COLUMN is the problem. This syntax is unsupported in versions of MariaDB prior to 10.5.3, here's the relevant documentation for reference: mariadb dot com/docs/server/reference/sql-statements/data-definition/alter/alter-table#rename-column The solution is to fix the usage of RENAME COLUMN in the current db_revs and to write a coding guideline and a QA test to accompany it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 37643] New: Check for NaN instead of truthiness if calendar.inc accepts_time
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37643 Bug ID: 37643 Summary: Check for NaN instead of truthiness if calendar.inc accepts_time Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org The check for truthiness in case calendar.inc accepts time (accepts_time = true) has one flaw: we can't set the time to 00:00. Let's fix it. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 40423] New: Handling x-koha-request-id relies on wrong data structure
by bugzilla-daemon＠bugs.koha-community.org 27 Dec '25

27 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40423 Bug ID: 40423 Summary: Handling x-koha-request-id relies on wrong data structure Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Processing the `x-koha-request-id` header relies on the fact the header is added to the 'reserved_params' earlier by the use of `$c->validation->output`. This is fragile as it relies on an internal data structure from the `Mojolicious::Plugin::OpenAPI` plugin that is not safe or intended to be accessed. Bug 40417 deals with removing that last use in `objects.search_rs` but highlights this situation. In order to keep things clear, I file this bug for dealing with this particular situation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20