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

[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

[Bug 37711] New: IdP auto-register should work on the staff interface
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37711 Bug ID: 37711 Summary: IdP auto-register should work on the staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Right now it only works if the login happens in the OPAC. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 87

[Bug 28318] New: accounlintes.credit_number missing on the API
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28318 Bug ID: 28318 Summary: accounlintes.credit_number missing on the API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com It was added to the DB structure, but bug 28272 skipped it so we could ponder if it is required on the API object and how should we name it. Feels like 'credit_sequence_number' could be a good name for it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 28964] New: request.pl slow to load when there are many holds on a record
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28964 Bug ID: 28964 Summary: request.pl slow to load when there are many holds on a record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In a large consortium popular titles have many holds - a record with 700 holds takes about 24 seconds to load When trying to place a hold we shouldn't have to wait for all holds to load. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29124] New: Load existing holds requests using API
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29124 Bug ID: 29124 Summary: Load existing holds requests using API 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We generate a lot of data when a record has many holds and we load the table of existing holds - we should load this dynamically after the page load using the API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27515] New: Search for both cases
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27515 Bug ID: 27515 Summary: Search for both cases Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When searching for the book "The Sawdust Dream", if you search for "sawdust dream", you get the item in the results. When you search for "sawdust dreams", you get nothing. It would be great if Koha would check for singular iterations of words used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 41899] New: Add branchcode in accountlines.branchcode for RESERVE_EXPIRED
by bugzilla-daemon＠bugs.koha-community.org 20 Feb '26

20 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41899 Bug ID: 41899 Summary: Add branchcode in accountlines.branchcode for RESERVE_EXPIRED Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org We need to record the branchcode to the accountlines when the RESERVE_EXPIRED fee is added by the cancel_expired_holds.pl cron job. I think the suitable branchcode could be the hold's pickup library (reserves.branchcode). This change would help to track to which library the fee belongs to (in library consortiums). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0