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

[Bug 40726] New: Clicking off of a dropdown in the user menu branch switching closes the dropdown
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40726 Bug ID: 40726 Summary: Clicking off of a dropdown in the user menu branch switching closes the dropdown Change sponsored?: --- 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: bdaeuber(a)cityoffargo.com 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 When using the user menu switching, if you miss the dropdown and click anywhere behind it, it closes the menu. I'd expect the menu to stay open unless I click elsewhere on the page, outside of the menu. To recreate 1. Open the user menu 2. Click the gear 3. Try to click a dropdown but miss it and click outside of it 4. View the menu collapsing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 19316] New: Items should have sort1 and sort2 fields
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19316 Bug ID: 19316 Summary: Items should have sort1 and sort2 fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Librarians love data, like for real, they can't get enough. We often find that libraries want extra information in their items table, things that don't fit or don't belong in any of the existing columns. Borrowers have sort1 and sort2 for this kind of information - we should add analogous fields to the items table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 27115] New: Restarting koha-common fails to restart SIP2 server
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27115 Bug ID: 27115 Summary: Restarting koha-common fails to restart SIP2 server Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Sometimes when we run "systemctl restart koha-commmon" the SIP server doesn't get restarted but might just get stopped leading to longer than expected downtime. There is probably some sort of race condition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 41253] New: Item Modification by Age should have its own permission
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41253 Bug ID: 41253 Summary: Item Modification by Age should have its own permission 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: alex(a)rcls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, access to the Item Modification by Age tool is determined by the items_batchmod permission. In a Consortium setting, a common scenario is to restrict item editing, including batch item editing, to staff users of the item owning library. This is done via Library Groups and the standard edit_items permission. However, the Item Modification by Age tool does not restrict the items.homebranch condition, allowing users of any library to define a new rule for a library they don't belong to and whose items they don't own. Breaking the tool permissions into two separate permissions would solve this issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 28308] New: Select 'Days in advance' = 0 for Advance notice effectively disables PREDUE notices
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28308 Bug ID: 28308 Summary: Select 'Days in advance' = 0 for Advance notice effectively disables PREDUE notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Looking at the code below, it seems that on the day an item is due we will only send the DUE notices, predues will not be sent In the advance_notices.pl cron: 276 if ( 0 == $upcoming->{'days_until_due'} ) { 277 # This item is due today. Send an 'item due' message. ... 323 } else { 324 $borrower_preferences = C4::Members::Messaging::GetMessagingPreferences( { borrowernumber => $upcoming->{'borrowernumber'}, 325 message_name => 'advance_notice' } ); 326 next UPCOMINGITEM unless $borrower_preferences && exists $borrower_preferences->{'days_in_advance'}; 327 next UPCOMINGITEM unless $borrower_preferences->{'days_in_advance'} == $upcoming->{'days_until_due'}; In this case, allowing the user to choose '0' is effectively disabling the notice. I think we need to remove 0 as an option, and uncheck all transports for patrons who have '0' set for days in advance -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 41451] New: Hold history search fails when itemtype column present
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41451 Bug ID: 41451 Summary: Hold history search fails when itemtype column present Initiative type: --- Sponsorship --- status: 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The search box on the holds history table throws a 500 error when the item type column is visible Test plan: 1) Create at least one hold on any record 2) Navigate to the patron who has the hold and click Holds history in the left menu 3) The table should load correctly and the search bar above it should work 4) In system preferences, enable AllowHoldItemTypeSelection 5) Refresh the holds history, the Requested item type column should now be visible 6) Try a search, a 500 error should be thrown -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 40287] New: Fix untranslatable strings in more statistics wizards
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40287 Bug ID: 40287 Summary: Fix untranslatable strings in more statistics wizards Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Depends on: 20601 The acquisitions, patrons, and catalog circulation statistics wizards have the same translation issues fixed in Bug 20601 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20601 [Bug 20601] Untranslatable strings in circulation statistics -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 41648] New: KitchenSink plugin breaks the plugins home page
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41648 Bug ID: 41648 Summary: KitchenSink plugin breaks the plugins home page Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Install the KitchenSink plugin and you get: Template process failed: undef error - The given date (20-12-20) does not match the date format (iso) at /kohadevbox/koha/Koha/DateUtils.pm line 192. on /cgi-bin/koha/plugins/plugins-home.pl Because Koha/Plugin/Com/ByWaterSolutions/KitchenSink.pm: date_updated => "1900-01-01", -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 20846] New: Suppressed Records Still Appear in Public Lists
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20846 Bug ID: 20846 Summary: Suppressed Records Still Appear in Public Lists Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1. Add a title to a public list 2. Edit the 942$n to suppress the record 3. Confirm that the record isn't visible in the opac 4. Confirm that the title still shows in the list It'd be great to have suppressed records hidden from lists. Even if the link from the list to the bib takes the user to the blocked record page, showing the title in the list is confusing. -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 41070] New: No warning when filling no fund while importing in a basket from a file
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '26

21 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41070 Bug ID: 41070 Summary: No warning when filling no fund while importing in a basket from a file Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Steps to reproduce. 1 - Go to any record and click save -> marc (Unicode/utf8) 2 - Go to any vendor and add a basket 3 - In this basket, create a new order from file, use the generated file and wait for the end of the import. Click on add staged files to basket. 4 - Select the record, fill in the required information and make sure no Fund is filly, neither in first or third tab. 5 - Validate: There will be no error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26