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

[Bug 40488] New: "Public lists" breadcrumb link doesn't work when editing public list in staff interface
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40488 Bug ID: 40488 Summary: "Public lists" breadcrumb link doesn't work when editing public list in staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you go to http://localhost:8081/cgi-bin/koha/virtualshelves/shelves.pl?op=edit_form&s… and try to click "Public lists" in the breadcrumbs, it just takes you to http://localhost:8081/cgi-bin/koha/virtualshelves/shelves.pl?op=edit_form&s… Note the hash on the end of the URL after clicking the breadcrumb. Note that this only affects public lists. Private/Your lists works. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 40937] New: No option to show/hide data menu in report results when including borrowernumber
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40937 Bug ID: 40937 Summary: No option to show/hide data menu in report results when including borrowernumber Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 37188 When borrowernumber was added as an option for batch patron action from reports, it didn't get added to the IF statement that makes the Show/Hide Data Menus button appear. It only knows to show up for cardnumber, biblionumber, itemnumber, or reserve_id. (https://github.com/Koha-Community/Koha/blob/99283025fc4ca0fa1c096344a47b380…) In a fun little twist, we told Koha to not set batch_cardnumbers if batch_borrowernumbers was already set, to stop the batch operations from showing up twice. (https://github.com/Koha-Community/Koha/blob/99283025fc4ca0fa1c096344a47b380…) To recreate: 1 - save and run "SELECT borrowernumber FROM borrowers" - no Show/Hide button 2 - save and run "SELECT cardnumber FROM borrowers" - yes Show/Hide button! 3 - save and run "SELECT cardnumber, borrowernumber FROM borrowers" - no Show/Hide button 4 - save and run "SELECT cardnumber, borrowernumber, itemnumber FROM issues LEFT JOIN borrowers USING (borrowernumber)" - yes Show/Hide button! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37188 [Bug 37188] Batch patron modification from report results should be an option when borrowernumber is selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39881] New: Add patron cardnumber to On hold for column on transferstoreceive page
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39881 Bug ID: 39881 Summary: Add patron cardnumber to On hold for column on transferstoreceive page 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 It would be nice if the patron's cardnumber was included in the 'On hold for' column on transferstoreceive.tt -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 39423] New: Column checkboxes on item batch modification hide incorrect columns
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39423 Bug ID: 39423 Summary: Column checkboxes on item batch modification hide incorrect columns Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It looks like the 'Hold' column is not taken into account in the numbering, unchecking any column removes the next column over -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 40128] New: StripWhitespaceChars can create empty subfields
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40128 Bug ID: 40128 Summary: StripWhitespaceChars can create empty subfields 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: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When StripWhitespaceChars is enabled and the user by chance enters some white spaces in the input field, Koha generates empty subfield (or even entirely empty field). To reproduce: 1. Enable StripWhitespaceChars system preference. 2. Edit an existing record, putting just some spaces into an empty subfield. Save the record. 3. Go to bibliographic record Normal view and in modal "MARC preview" notice that the subfield you entered spaces in exists as an empty subfield. If it was the only subfield in a field, the field exists with no data at all. This is wrong. Koha::Filter::MARC::TrimFields::filter should be corrected to avoid this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 39623] New: "make install" re-runs "make" process unnecessarily
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39623 Bug ID: 39623 Summary: "make install" re-runs "make" process unnecessarily Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Have you ever noticed that "make install" seems to do all the same things as "make" plus install? This became even more obvious after bug 32609. And it got me thinking... surely there has to be a better way and it looks like there is. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 39212] New: Error when attempting to edit 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=39212 Bug ID: 39212 Summary: Error when attempting to edit a booking Change sponsored?: --- Product: Koha Version: unspecified 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. Make an item or item type 'Bookable' 2. Place a booking for that item 3. Go the 'Bookings' tab for that item. 4. Edit the booking 5. Submit the edit request and see at the top of the modal "Failure" I also see something like this in the console: PUT http://localhost:8081/api/v1/bookings/10 400 error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 39570] New: Add item form includes itemnumber while adding a new item
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39570 Bug ID: 39570 Summary: Add item form includes itemnumber while adding a new item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 36192 Luckily, submitting an itemnumber that's either empty or bogus while adding a new item doesn't actually do anything since the code for op == 'cud-additem' doesn't ever look at itemnumber, but it's confusing and scary looking in the case where you add an item after editing an existing item. The template looks at [% IF op != 'add_item' %] to decide to add the <input type="hidden" name="itemnumber" value="[% itemnumber | html %]" />. Prior to the bug 36192 CSRF protection, that worked, but now the op for adding an item is cud-additem, so it's always true and we always submit an itemnumber. And without bug 27625 it would have been less scary looking, since before then while processing the editing of an item we cleared $itemnumber after we were done using it, so it at least would have been value="". Now, if you edit an existing item and then add another, the form you submit to add an item includes the itemnumber of the item you previously edited. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39663] New: Patrons entry in additional fields has wrong header
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39663 Bug ID: 39663 Summary: Patrons entry in additional fields has wrong header Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: pedro.amorim(a)openfifth.co.uk Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: katrin.fischer(a)bsz-bw.de CC: gmcharlt(a)gmail.com Depends on: 38662 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38662 [Bug 38662] Additional fields admin page hard to read -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 39029] New: When a basket contains an order transferred from another basket some info is incorrect
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39029 Bug ID: 39029 Summary: When a basket contains an order transferred from another basket some info is incorrect Change sponsored?: --- 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a basket has orders transferred from another basket we do this: [% IF (books_loo.transferred_from) %] [% basket = books_loo.transferred_from.basket %] [% bookseller = books_loo.transferred_from.bookseller %] [% timestamp = books_loo.transferred_from.timestamp %] But later when building the 'Add to basket' modal - we have this: <div id="addtoBasket" class="modal" tabindex="-1" role="dialog" aria-labelledby="addtoBasketLabel" aria-hidden="true" data-basketno="[% basket.basketname | html %]"> We are using the wrong basket now to pull info -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19