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

[Bug 42862] New: bookingsModalDatePicker_spec.ts is failing
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42862 Bug ID: 42862 Summary: bookingsModalDatePicker_spec.ts is failing Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The file bookingsModalDatePicker_spec.ts has a test that checks a booking calendar using hardcoded June 2026 dates, faking "today" as 2026-06-01 so those dates look like the future. That fake date is lost when the test reloads the page midway through, so the real date takes over causing it to fail. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 21821] New: We should bundle and up to date RangeMessage.xml for Business::ISBN
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21821 Bug ID: 21821 Summary: We should bundle and up to date RangeMessage.xml for Business::ISBN Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Business::ISBN::Data isn't especially maintained and suggests using an up to date RangeMessage.xml file from https://www.isbn-international.org/range_file_generation. We should bundle a more up to date RangeMessage file with koha and set the appropriate environment in both plack and apache to point to the bundled version. This would help with new ISBN's that are not yet in the shipped Business::ISBN::Data package. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 42126] New: t/db_dependent/00-strict.t not testing all perl files
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42126 Bug ID: 42126 Summary: t/db_dependent/00-strict.t not testing all perl files Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org First it lists explicitly the directories to process. Obviously it hasn't been kept up-to-date and some are missing (eg.booking). Also Koha is missing (!). Then we should process the files that are in the git repository, and use Koha::Devel::Files to list them. -- You are receiving this mail because: You are watching all bug changes.

1 18

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

29 Jun '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 1

[Bug 31162] New: Add a clear cataloguing module home page
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31162 Bug ID: 31162 Summary: Add a clear cataloguing module home page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 cataloguing module doesn't really have a 'home page' like circulation does. We have a number of tools under the cataloguing banner, we could have a clear jump-in point on the module home page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 178

[Bug 42935] New: Koha::Item->_status croaks when an item references a non-existent item type
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42935 Bug ID: 42935 Summary: Koha::Item->_status croaks when an item references a non-existent item type Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Item->_status calls $self->item_type->notforloan. item_type resolves via Koha::ItemTypes->find( $self->effective_itemtype ), which returns undef when the item's effective item type is set to a value that has no matching row in the itemtypes table. _status then croaks with: Can't call method "notforloan" on an undefined value at Koha/Item.pm This is the non-NULL-but-invalid case (an orphaned itype value, not an empty one). Impact: a 500 on GET /api/v1/biblios/{biblio_id}/items (the _status embed), so the catalogue detail items table fails to load for the whole record if any one of its items references a non-existent item type. The state is not reachable through normal editing; it arises out of band, e.g. deleting an item type still referenced by items, or an SQL import/migration - which Koha already flags as a data inconsistency (Koha::Database::DataInconsistency::invalid_item_type). To reproduce (item-level itypes): 1. UPDATE items SET itype = 'NOPE' WHERE itemnumber = <X>; ('NOPE' being any value absent from the itemtypes table) 2. Open that record's detail page in the staff interface. => the items table fails to load; the plack log shows the croak above. Expected: the item row loads; a non-existent item type must not be treated as a croak (and should not count as not-for-loan). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 42934] New: Koha::Item->home_library/holding_library croak when an item's branch is NULL
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934 Bug ID: 42934 Summary: Koha::Item->home_library/holding_library croak when an item's branch is NULL Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- items.homebranch and items.holdingbranch are nullable. When either is NULL, Koha::Item->home_library / ->holding_library croak with: DBIC result _type isn't of the _type Branch Impact: a 500 on GET /api/v1/biblios/{biblio_id}/items, so the catalogue detail items table fails to load for the whole record if any one of its items has a NULL home or holding branch. The NULL state is not reachable through normal item creation/editing (those always set the columns), only via out-of-band data such as an SQL import or migration, which Koha already flags as a data inconsistency (Koha::Database::DataInconsistency::invalid_item_library). To reproduce: 1. UPDATE items SET holdingbranch = NULL WHERE itemnumber = <X>; 2. Open that record's detail page in the staff interface. => the holdings table fails to load; the plack log shows the croak above. Expected: the item row loads, with an empty home/holding library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 5789] Fines don't work when items have null homebranch
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5789 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |RESOLVED Resolution|--- |WONTFIX --- Comment #19 from Jonathan Druart <jonathan.druart(a)gmail.com> --- Marking invalid. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 31314] New: Remove GetItemsInfo from opac-reserve.pl
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31314 Bug ID: 31314 Summary: Remove GetItemsInfo from opac-reserve.pl 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+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 31306 Blocks: 27272 Bug 27272 is going to remove C4::Items::GetItemsInfo in favour of Koha::Items->search_ordered. Here we are going to deal with opac-reserve.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27272 [Bug 27272] Move C4::Items::GetItemsInfo to Koha namespace https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31306 [Bug 31306] Add Koha::Items->search_ordered method -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 36957] New: Item in transfer should start floating in its floating library without user clicking the "Cancel transfer"-button
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '26

29 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36957 Bug ID: 36957 Summary: Item in transfer should start floating in its floating library without user clicking the "Cancel transfer"-button Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When item is in transfer and it is checked in in a library where it could float, a notification/pop-up about transport will appear on the screen. User must end the transfer by clicking “Cancel transfer”-button. Only then will the item end the transport and start floating in the holding library. Even if the item is in transfer somewhere else (and there are no holds waiting) and it is checked in in a floating library, it should not give the pop-up: “Wrong transfer detected, please return item to…” . Instead it should just start floating without having to click the canceling-button. Koha asks for transfer cancelation even if we have saved in the AutomaticItemReturn-preference “Don’t automatically transfer items to their home library when they are checked in.” -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10