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

[Bug 42335] New: Accessibility of top level menu (staff interface)
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42335 Bug ID: 42335 Summary: Accessibility of top level menu (staff interface) Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: raina(a)flo.org 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 In the top level menu (#toplevelmenu) in the staff interface, the dropdown icon (#catalog-search-dropdown) that expands to show the Advanced and Item search options does not have any label for assistance technology. The Cart icon in the same menu also does not have any label. Because both have href attributes but no labels or link text, a screen reader may read these as "link" (tested with VoiceOver), making it unclear to the user what they are when user is navigating through the menu. For the dropdown icon that goes to Search options, this does follow the "Search" text in the top level menu, but it could be made more clear to all users that this is an icon to toggle show search options (such as with an aria-label), whereas clicking the "Search" text will to the Advanced search page. The shopping cart icon could simply have an aria-label. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 40704] New: When item is deleted, title disappears from reading history creating a useless entry
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40704 Bug ID: 40704 Summary: When item is deleted, title disappears from reading history creating a useless entry Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When an item that was formerly checked out to a user is deleted, it leaves an empty entry in their circulation history in the OPAC. Star ratings and date will display, the rest of the cells, including the title information, will be empty. To test: * Activate opacreadinghistory * Check out an item to your user * Confirm circulation history in OPAC shows it * Check in the item and delete it * Verify that now the reading history has an (almost) empty line -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 42661] New: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42661 Bug ID: 42661 Summary: Redudant repetition in "Patron: %s Patron's home library: (%s /%s )" when HidePatronName is activated Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When making a reservation for a patron whose home library differs from the library where the staff member is logged in, the current notification contains redundant repetition when system preference HidePatronName is "Don't show". Steps to Reproduce: 1. Log in as staff to a library. 2. Set HidePatronName as "Don't show" 3. Attempt to reserve an item for a patron whose home library is different from the current logged-in library. 4. Observe the notification: Pickup library is different. Patron: A patron from library Midway Patron's home library: (Midway / MPL ) This text comes from the string Patron: %s Patron's home library: (%s /%s ) (%1$s: INCLUDE 'patron-title.inc' patron => patron no_title => 1 no_cardnumber => 1 hide_patron_infos_if_needed => 1 %2$s: Branches.GetName(patron.branchcode) | html %3$s: patron.branchcode | html) And the '%s' has it's own translation: %1$s: - Branches.GetName( patron.branchcode ) | html - A patron from library %s Can these sentences be clarified in any ways to avoid repeating the library name? It is okay when the sentence contains the patron name but when HidePatronName is activated it gets confusing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 42646] New: ModSuggestion: SMS status-change notices always contain email template content
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42646 Bug ID: 42646 Summary: ModSuggestion: SMS status-change notices always contain email template content Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org In C4/Suggestions.pm, ModSuggestion() selects the transport type (email or sms) at ~line 253 and stores it in $transport, but then calls GetPreparedLetter() at ~line 256 without passing message_transport_type. GetPreparedLetter() defaults message_transport_type to 'email' when the parameter is absent (C4/Letters.pm ~line 585), so it always fetches the email template variant of the notice â even when $transport was resolved to 'sms'. The result is that any patron who legitimately receives an ACCEPTED/AVAILABLE/REJECTED/ORDERED/CHECKED notice via SMS receives the email-formatted body text rather than the SMS-specific template content. Related to: Bug 39984, Bug 42645 Test plan: 1. Configure SMSSendDriver and a patron with smsalertnumber but no email. 2. Enable FallbackToSMSIfNoEmail. 3. Create SMS-specific templates for the ACCEPTED notice code (Notices > ACCEPTED > SMS tab). 4. Submit a suggestion as that patron and accept it. 5. Check the message_queue table: the content column will contain the email template body, not the SMS template body. 6. Apply patch (add message_transport_type => $transport to the GetPreparedLetter() call in ModSuggestion). 7. Repeat: the content column now contains the SMS template body. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 36254] New: Port default PASSWORD_RESET and STAFF_PASSWORD_RESET notices to Template Toolkit syntax
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36254 Bug ID: 36254 Summary: Port default PASSWORD_RESET and STAFF_PASSWORD_RESET notices 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 These might require a bit of refactoring. Looking at Recovery.pm, it looks like the subroutine is passing a custom key/value pair for passwordreseturl, so I'm not sure if an equivalent has been added for Template Toolkit syntax yet. Also not sure if there are any security implications to consider? 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 the assignee for the bug. You are watching all bug changes.

1 2

[Bug 40575] New: Transferring order will reload the page and its form
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40575 Bug ID: 40575 Summary: Transferring order will reload the page and its form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Test plan: 1 - Create two baskets: "Source Basket" and "Dest Basket" 2 - Add one command line to "Source Basket" 3 - Close the basket 4 - Receive shipment 5 - Receive order 6 - Cancel the order receive 7 - Transfer the order to the Dest Basket -> When clicking on chose, you will be asked if you want to send again infos (which were sent to cancel the order receive), and if accepting, you will be printed an error. 8 - Apply patch 9 - Repeat the process with another source Basket and notice the page is simply reloaded without sending form. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 36540] New: Consider modernising the checkout page to be an Vue page
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36540 Bug ID: 36540 Summary: Consider modernising the checkout page to be an Vue page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The checkouts page is a core function of Koha, The controller has grown very complicated and it can suffer from performance challenges that we keep trying to side step wit preferences work arounds. We should consider working to replace the page with a Vue app and use the modern API's that have been developed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 35440] New: Partial refund triggers a 500 error
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35440 Bug ID: 35440 Summary: Partial refund triggers a 500 error Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate 1. Create a charge on a patron account of $150.00 2. Pay the charge as cash 3. Issue a refund, but only refund $5.00 as cash 4. See that it causes a 500 error I should be able to issue a partial refund and have it show correctly in the transaction table. Error statement: Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to payout (5.00) is higher than amountoutstanding (0)' May be connected to bug 30027 and previously fixed bug 8770. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 23185] New: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store'
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185 Bug ID: 23185 Summary: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high 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 CC: dcook(a)prosentient.com.au, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 21761 Target Milestone: --- +++ This bug was initially created as a clone of Bug #21761 +++ If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing the 'update' method through we are exposing ourselves to places in the codebase skipping the store triggers. This would in effect bind us to the 'update_all' style of update call from dbic, which results in a loop over the affected rows so that in code triggers can be called per row rather than allowing any form of 'update all these rows to X' in one query. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21761 [Bug 21761] Koha::Object supports passing through 'update' which means we can side step 'set' + 'store' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are on the CC list for the bug.

1 71