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

[Bug 34611] New: Add a script for pseudonymizing existing data
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34611 Bug ID: 34611 Summary: Add a script for pseudonymizing existing data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some libraries would like to eliminate old statistics, but keep the data for reporting. While pseudonymization works on new transactions once enabled, it would be nice to have a method to pseudonymize older transactions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 38509] New: Displayed transfer destination is incorrect when a reservation has been found
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38509 Bug ID: 38509 Summary: Displayed transfer destination is incorrect when a reservation has been found 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: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com TEST PLAN FOR 24.05 (transfers appear to be broken on main atm, code is still invalid on main) 1 - Place a hold for Henry Acevedo on "39999000001334" (item level), ask for a pickup at centerville 2 - At centerville, transfer the document to fairfield. There will be a pop-up giving you three choices. The first one is "transfer to centerville", which is not the behaviour or the button. The correct text is "transfer to fairfield". The button must display the branch selected for the transfer and not the pickup location for the reservation (which is the branch at which we are located.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 41907] New: Tone down warning about Zebra not running if Elasticsearch is used
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41907 Bug ID: 41907 Summary: Tone down warning about Zebra not running if Elasticsearch is used Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org To reproduce in KTD: - Start KTD with Elasticsearch, e.g. $ ktd --search-engine es7 up - Stop Zebra: $ sudo koha-zebra --stop kohadev - Go to About Koha For "Zebra status" there is a warning in bold letters on a red background: "Zebra server seems not to be available. Is it started?" I would say it is OK to have a warning there about Zebra not running, but if SearchEngine = Elasticsearch it should not look like there is a serious problem with the system. Non-bold letters on neutral background should be enough. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 32142] New: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already"
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '26

22 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32142 Bug ID: 32142 Summary: Add HoldFeeMode option "if all items are checked out OR the record has at least one hold already" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Relates to Bug 31963. There is an option for the HoldFeeMode system preference "only if all items are checked out and the record has at least one hold already", except it behaved more like "if all items are checked out OR the record has at least one hold already". Bug 31963 fixed this so that the behaviour better matches the description i.e. it says 'and' so that implies BOTH conditions must be met. However we now need an option so that the behaviour from before isn't lost, behaviour like "if all items are checked out or the record has at least one hold already" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 30295] New: Send a notification when a recall is manually cancelled
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '26

22 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30295 Bug ID: 30295 Summary: Send a notification when a recall is manually cancelled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The process would be: 1. Recall is cancelled by library staff or the requester. 2. Notification of the recall cancellation is sent via email and SMS to the recall requester. So it would be exactly the same as the HOLD_MANUAL_CANCEL notice that we currently have for reserves, only relevant to recalls. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 78

[Bug 41868] New: Export Catalog Data from List
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '26

21 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41868 Bug ID: 41868 Summary: Export Catalog Data from List 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: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be great if in Export Catalog Data, there was an option to export bibs from a list. Additionally (or alternatively) it would great if there was an Export Catalog Data directly from the list screen. At the very least, a quick way to download biblionumbers from a list would save some steps. There have been multiple times that this would have been useful, but my current use case is for identifying bib records that have faulty diacritics (ie. {u1EA3} instead of ậ.) There are dozens of these characters to look for, so I would love to be able to add all the bibs to a list as I come across them and then export it so that I can fix the characters in MarcEdit. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27213] New: Convert vendor search box to a dropdown
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '26

21 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27213 Bug ID: 27213 Summary: Convert vendor search box to a dropdown Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org Convert the vendor search box on acqui-home.pl to a dropdown so that it's possible to select a vendor from the list rather than having to type it in which would be more efficient. Also there are times when I don't remember the name of vendor and seeing it in the list of choices would be helpful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 41905] New: Local cover images are not displayed in the OPAC public list page (opac-shelves.pl)
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '26

21 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41905 Bug ID: 41905 Summary: Local cover images are not displayed in the OPAC public list page (opac-shelves.pl) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sunil.kumar(a)bestbookbuddies.com QA Contact: testopia(a)bugs.koha-community.org When viewing a public list in OPAC (opac-shelves.pl), cover images are displayed using a lightbox/slider mechanism. Cover images are loaded based on enabled system preferences,for e.g. including: - OPACAmazonCoverImages - GoogleJackets - OpenLibraryCovers - LocalCoverImages All available cover sources should be included in the lightbox slider. Issue: Local cover images are not included in the OPAC list page lightbox slider, regardless of whether external cover images (Amazon, Google, OpenLibrary) are available. Observed behavior: Scenario A – External cover images available: 1. A bibliographic record has a cover image available from Amazon, Google, or OpenLibrary. 2. A local cover image is also uploaded for the same record. 3. On OPAC search results and bibliographic detail pages, the local cover displays correctly. 4. On the OPAC public list page (opac-shelves.pl), the lightbox slider displays only external cover images. 5. The local cover image is not included in the slider. Scenario B – No external cover images available: 1. A bibliographic record has no cover image available from Amazon, Google, or OpenLibrary. 2. A local cover image is uploaded for the record. 3. On OPAC search results and bibliographic detail pages, the local cover displays correctly. 4. On the OPAC public list page (opac-shelves.pl), no cover image is displayed. 5. The local cover image is not shown. Apply the Patch: The attached patch modifies opac/opac-shelves.pl to ensure that local cover images are correctly included in the cover image rendering logic for the OPAC list page. Test Plan: 1. Enable the following system preferences: - OPACAmazonCoverImages - GoogleJackets - OpenLibraryCovers - LocalCoverImages 2. Create a public list and add bibliographic records. 3. Scenario A: a. Select a record with an available external cover image. b. Upload a local cover image for the same record. c. View the public list in OPAC. d. Confirm the local cover image appears in the lightbox slider. 4. Scenario B: a. Select a record with no external cover images available. b. Upload a local cover image. c. View the public list in OPAC. d. Confirm the local cover image is displayed. 5. Verify that: - OPAC search results & bibliographic detail pages continue to display covers correctly. - No regressions occur in cover image rendering. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 41182] New: Sushi harvest should send a full date
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41182 Bug ID: 41182 Summary: Sushi harvest should send a full date Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk A library attempting to get counter reports from Proquest found they were failing. In testing, I was able to narrow the problem down to the date range. We send: https://sushi.proquest.com/counter/r5/reports/pr?begin_date=2024-11&end_dat… They expect: https://sushi.proquest.com/counter/r5/reports/pr?begin_date=2024-11-01&end_… >From what I can tell in the standard: https://www.niso.org/sites/default/files/schema-files/sushi1_7_ReportReques… Date is expected as yyyy-mm-dd We should send the full date and not truncate -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 32801] New: /checkouts?checked_in=1 errors when itemnumber is null
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32801 Bug ID: 32801 Summary: /checkouts?checked_in=1 errors when itemnumber is null Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com CC: tomascohen(a)gmail.com When trying to fetch checked_in checkouts for a borrower, if the old_issues doesn't have an itemnumber (for example the item was deleted). It brings a 500 error. This is a message I got while querying this url : /api/v1/checkouts?patron_id=13662&checked_in=1 <pre> {"errors":[{"message":"Expected integer - got null.","path":"\/0\/item_id"},{"message":"Expected integer - got null.","path":"\/1\/item_id"},{"message":"Expected integer - got null.","path":"\/9\/item_id"},{"message":"Expected integer - got null.","path":"\/12\/item_id"},{"message":"Expected integer - got null.","path":"\/13\/item_id"},{"message":"Expected integer - got null.","path":"\/14\/item_id"},{"message":"Expected integer - got null.","path":"\/15\/item_id"}],"status":200} </pre> Querying with itemnumber not null solves the issue : /api/v1/checkouts?patron_id=13662&checked_in=1&q={"item_id":{"-not_like":"null"}} -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17