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

[Bug 39644] New: Too many borrower_relationships causes patron page to not load
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39644 Bug ID: 39644 Summary: Too many borrower_relationships causes patron page to not load Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: In k-t-d, if I add 53 guarantees for Edna Acosta it takes about 8-10 seconds for the patron page to load. If I add 700 guarantees for Edna Acosta the page won't load and I ultimately get a time out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 39588] New: Bookings to collect report won't load when the search returns currently checked out bookings
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39588 Bug ID: 39588 Summary: Bookings to collect report won't load when the search returns currently checked out bookings Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(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. Turn on bookings for an item or item type 2. Find an item and book it. 3. Check the same item out. 4. Go to Circulation > Bookings to collect and run the report 5. The table never loads Uncaught TypeError: _(...).$date is not a function -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 39414] New: Item type not retained when editing a booking
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39414 Bug ID: 39414 Summary: Item type not retained when editing a booking Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When editing an existing booking, the Patron, Pickup at, and Item are retained, but the Itemtype will be de-selected. The booking cannot be edited until the item type is re-selected. The booking dates are also not retained in the edit booking window, but this was existing behavior. To re-create: 1. Place a booking on an item. 2. Click on edit to open the Edit booking modal. 3. The item type will be de-selected, and the booking dates calendar will be locked until the item type is re-selected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 39397] New: Searching a biblio by timestamp returns a different timestamp
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39397 Bug ID: 39397 Summary: Searching a biblio by timestamp returns a different timestamp Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal 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 When crafting a search including the `timestamp` field, the comparison is made against the `biblio.timestamp` column. But the result displays the `biblioitem.timestamp`. I believe filtering and the returned objects should be consistent. On the other hand, I feel like the real source for truth is the biblio_metadata.timestamp column. Thoughts? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 39294] New: Not all settings stick when when staging MARC records for import
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39294 Bug ID: 39294 Summary: Not all settings stick when when staging MARC records for import Change sponsored?: --- 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Cataloging > Stage MARC record for import 2. Upload a MARC file 3. Change some of the following settings: -Action if matching record found: -Action if no match is found: -How to process items/Item processing: 4. Stage for import and View batch 5. None of this settings have been retained. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 39056] New: Do not copy preferred_name to new patron when using Duplicate
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39056 Bug ID: 39056 Summary: Do not copy preferred_name to new patron when using Duplicate Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the Duplicate button from a patron's record, we make a new patron with some of the original patron's info. We bring the surname to the new patron, but not the firstname. Following that logic, we shouldn't copy preferred_name, either. Currently on main the preferred_name *is* copied to the new patron. In the long run this probably wants something like the PrefillGuaranteeField syspref, but in the short term we should just exclude preferred_name. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 38927] New: Unecessary call to FindDuplicate if x-confirm-not-duplicate is passed to POST /biblios
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38927 Bug ID: 38927 Summary: Unecessary call to FindDuplicate if x-confirm-not-duplicate is passed to POST /biblios Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Depends on: 31800 695 my ( $duplicatebiblionumber, $duplicatetitle ); 696 ( $duplicatebiblionumber, $duplicatetitle ) = FindDuplicate($record); 697 698 my $confirm_not_duplicate = $headers->header('x-confirm-not-duplicate'); 699 700 return $c->render( 701 status => 400, 702 openapi => { 703 error => "Duplicate biblio $duplicatebiblionumber", 704 } 705 ) unless !$duplicatebiblionumber || $confirm_not_duplicate; We don't need to call FindDuplicate if the header is set. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31800 [Bug 31800] Add POST endpoint for Biblios -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 38870] New: Remove overflow scroll from batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38870 Bug ID: 38870 Summary: Remove overflow scroll from batch patron modification Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Bug 37730 fixed problems with the batch patron modification DataTable when scrolling horizontally and vertically. Since the DataTables upgrade there are new problems, so I propose we remove the container around the table which has "overflow:auto" and the DataTables option "scrollX". This will make the page behave like others, where wide tables cause a full page horizontal scroll. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 38845] New: OpacNoItemTypeImages required to show item type images in staff interface advanced search
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38845 Bug ID: 38845 Summary: OpacNoItemTypeImages required to show item type images in staff interface advanced search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/advsearch.tt, there is this line [% UNLESS ( Koha.Preference('OpacNoItemTypeImages') ) %] However, the item type images in the staff interface are (should be) managed by noItemTypeImages. To test: 1. Add images to item types, if there aren't any already (KTD has them by default) 1.1. Go to Administration > Item types 1.2. Click 'Edit' next to one of the item types 1.3. Choose an icon 1.4. Click 'Save changes' 2. Disable OpacNoItemTypeImages 3. Enable noItemTypeImages (already enabled in KTD) 4. Go to the advanced search page --> The item types don't have any images next to them 5. Reenable OpacNoItemTypeImages and go back the the advanced search page --> The images are displayed -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 38783] New: Row highlighting table_readingrec members/readingrec.pl doesn't look great
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38783 Bug ID: 38783 Summary: Row highlighting table_readingrec members/readingrec.pl doesn't look great 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: lucas(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. Make some checkout to a patron so they have a circulation history, have some items checked in and some still on loan. 2. Look at the table, you can see that there can be 4 possible background colors for each row (#ffffff, #f3f4f4, #F9FAE0, and #FFFFCC ) I think that's is too many row colors and make the table look ... not great. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37