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

[Bug 41588] New: Link from 856$u breaks with leading or trailing spaces
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41588 Bug ID: 41588 Summary: Link from 856$u breaks with leading or trailing spaces Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Leading or trailing spaces in the 856$u add "%20" to the url, breaking it. To recreate: - add 856$u "www.cheese.com" to a record; it works! - add 856$u " www.cheese.com" to a record; it doesn't work - add 856$u "www.cheese.com " to a record; it doesn't work We've got a syspref to strip those characters out when editing a record, but we may as well also deal with spaces in the XSLT for old records and/or libraries that haven't enabled the syspref. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 41081] New: Link from 856$u points to http://%20%20%20%20
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41081 Bug ID: 41081 Summary: Link from 856$u points to http://%20%20%20%20 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl http://%20%20%20%20 We should not provide such useless links. The field only contained four spaces. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 34460] New: Patron category should regulate if account can have permissions
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34460 Bug ID: 34460 Summary: Patron category should regulate if account can have permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Permission management would be simpler if there were a setting in patron categories that indicate whether that category of patron can have permissions. - If no, that option would not appear in the patron menu. - If patron category is changed to a category that does not allow permissions, any existing permissions should be cleared when change is saved. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 23849] New: Update the list of sysprefs to share with Hea
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Update the list of sysprefs to share with Hea Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We have a lot of sysprefs that are not recorded in Hea. We lack a process to keep the list up-to-date. We are going to have an updated list for 19.11. For next releases it should be a new post release task (https://wiki.koha-community.org/wiki/Post_major_release_tasks) This bug report could be reused for the next releases. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 82

[Bug 39267] New: Specified due date remains for checkouts even when removing unchecking remember for session
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39267 Bug ID: 39267 Summary: Specified due date remains for checkouts even when removing unchecking remember for session Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When checking out an item for a borrower, choosing a specific due date and checking the "remember for session". If another checkout is done, removing the date and unchecking "remember for session", after the checkout has been performed, the previously set due date is still there. It's difficult to see how the correct behaviour shouldn't be that the date is cleared from the session as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 41199] New: Advanced Search fields could use more visible label options
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41199 Bug ID: 41199 Summary: Advanced Search fields could use more visible label options Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org The advanced search & search masthead could both do with more visible labels. This aids users in navigating the system, and also helps to provide screen readers with more context about an input field. We should offer a syspref that controls the number of visible labels, so libraries can have greater control over the extent of these labels. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 39296] New: Provide a template plugin to return MARC::Record for MARCXML metadata
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39296 Bug ID: 39296 Summary: Provide a template plugin to return MARC::Record for MARCXML metadata Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org ExtractValue() is a useful MySQL function but it's limited in what it can do. Sometimes, you want to do reporting off a more nuanced understanding of MARC. I had thought about exposing XML::LibXML::Document and XML::LibXML::XPathContext objects, but they're too powerful/vulnerable to abuse. Instead, I decided that MARC::Record should give all the power we need while not upsetting the status quo or security (after all, we already allow access to MARC::Record objects via $biblio objects in Templates). In this case, you fetch the whole "metadata" blob from the database in your report, and you transform it using a template using Koha::Template::Plugin::KohaMarcRecord It lets you perform more advanced reporting using the full MARC record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 41553] New: Add fund code to fund pulldown for order editor ( neworderempty.pl )
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41553 Bug ID: 41553 Summary: Add fund code to fund pulldown for order editor ( neworderempty.pl ) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It's possible to give multiple funds the same name. It would be helpful to have the fund code in the pulldown options to help disambiguate these funds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 35471] New: Automatically select child MARC framework when adding child records
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35471 Bug ID: 35471 Summary: Automatically select child MARC framework when adding child records Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries create their own MARC frameworks for component/child records. When adding a child record through host record, Koha currently selects the default MARC framework and a librarian must manually change to the child record framework. This Bug adds a parent-child relationship to MARC frameworks and aims to skip the manual step of selecting child record framework. The goal is to automatically select child MARC framework when adding child record through the host record. To reproduce problem: Administration -> MARC bibliographic framework 1. Create framework with frameworkcode "A" 2. Create framework with frameworkcode "A-child" Record view 1. Save record with framework "A" 2. Navigate to a record 3. Click "+ New", a drop-down opens 4. Click "New child record" 5. After add biblio form opens, click "Settings" 6. Observe default framework selected 7. You must manually select "A-child framework" After this change, To test: Administration -> MARC bibliographic framework 1. Create framework with frameworkcode "A" 2. Create framework with frameworkcode "A-child" 3. Set "A" as "A-child" 's parent framework Record view 1. Save record with framework "A" 2. Navigate to a record 3. Click "+ New", a drop-down opens 4. Click "New child record" 5. After add biblio form opens, click "Settings" 6. Observe "A-child" framework automatically selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 41730] New: Automate change Withdrawn status when item is paid for
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '26

22 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41730 Bug ID: 41730 Summary: Automate change Withdrawn status when item is paid for Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For many libraries, when a lost item is paid for the library does not want the item back -- it should not check in, it should not get marked found, it should not generate a lost fee refund. Functionally, the patron has purchased the book and gets to keep it (should they find it). It would be helpful for Koha to automatically apply a withdrawn status when an item is paid, similar to the UpdateItemLostStatusWhenPaid functionality added in Bug 22740. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16