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

[Bug 42701] New: Ability to click anywhere in item row for edit and delete options is missing
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42701 Bug ID: 42701 Summary: Ability to click anywhere in item row for edit and delete options is missing Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: performance Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We just noticed this behavior change when editing items on additem.pl. Catalogers can no longer click anywhere on the row for an item to get the edit/delete options. It has always been the case that the user could go to the specific item and could click in any cell within the row which would then display the links for 'Edit item' and 'Delete item' (see screenshot) Now the user must click specifically on the Actions dropdown button to get the list of five options. Being able to click in any cell and get the two most used links was a nice time saver because the user didn't have to focus on a specific button. It was really easy to just click and go. The ability to edit items in this way has been in effect at least since version 3.16 and our catalogers are not happy with losing this functionality. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 42466] New: UseCashRegisters gets ignored on paycollect
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42466 Bug ID: 42466 Summary: UseCashRegisters gets ignored on paycollect 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: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org - enable UseCashRegisters - go to /cgi-bin/koha/members/maninvoice.pl?borrowernumber=5 and create a manual fee f.e. 5 - go to /cgi-bin/koha/members/paycollect.pl?borrowernumber=5 -You will see: Total amount outstanding: 5.00 Amount being paid: 5.00 Amount tendered: 5.00 - Change Amount being paid: 4 Check Payment type is required. Click Confirm. The form will get sent even though the required cash register is not selected -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 41898] New: Expired bookings do not display when expired filter is used in patron record
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41898 Bug ID: 41898 Summary: Expired bookings do not display when expired filter is used in patron record Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Created attachment 193520 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=193520&action=e… Show expired button does not display expired bookings The 'Show expired' button in the Bookings tab of the patron record does not show expired bookings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 38412] New: Koha should warn when hold on bibliographic record requires hold policy override
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38412 Bug ID: 38412 Summary: Koha should warn when hold on bibliographic record requires hold policy override Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 Depends on: 35573 When AllowHoldPolicyOverride is set to Allow, Koha will specifically mark items for which an item-level hold will require an override. However, nothing in the interface indicates when the bibliographic level hold will require an override. To recreate: - Have AllowHoldPolicyOverride set to Don't Allow - Have a bib record with just one item - confirm you can place a hold on either the biblio or the item - edit your item such that it become unholdable (mark it Not For Loan or something) - confirm that you cannot place a hold on either the biblio or the item - set AllowHoldPolicyOverride to Allow - confirm that Koha shows an alert on the item indicating that the hold will require an override - confirm that Koha does not indicate the bibliographic level hold will require an override Bug 33573 restored these alerts for items. I don't recall if we've ever had these alerts for biblios. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35573 [Bug 35573] Koha is not correctly warning of overridden items when placing a hold if AllowHoldPolicyOverride -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 37570] New: Add possibility to send request on other url defined by a new syspref SearchAlsoIn
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37570 Bug ID: 37570 Summary: Add possibility to send request on other url defined by a new syspref SearchAlsoIn Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello Like OPACSearchForTitleIn I would like to purpose you a new syspref "SearchAlsoIn" which adds the possibility of defining urls to launch the query on other sites. This can be added on both sides (personal pages and OPAC results pages). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42634] New: Self-checkout Finish/logout does not reliably clear the JWT cookie
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42634 Bug ID: 42634 Summary: Self-checkout Finish/logout does not reliably clear the JWT cookie Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org On the web-based self-checkout (opac/sco/sco-main.pl), clicking the Finish/close button on the kiosk does not reliably end the patron session. The JS redirects the browser to ?op=logout, but the server-side response does not actually delete the JWT cookie - it emits an empty value with no Expires attribute, so the browser keeps a session-scoped empty cookie (or, in some intermediary/cache scenarios, retains the previous valid JWT). The patron remains logged in until the cookie genuinely expires, which presents as the Finish button "doing nothing" or working only intermittently. In opac/sco/sco-main.pl the Set-Cookie for JWT on logout is built as: -value => \$jwt // '', -expires => \$jwt ? '+1d' : '', Empty -expires produces a session cookie with an empty value rather than a deletion. The standard pattern for clearing a cookie is a past Expires, e.g. '-1d'. Test plan: 1. Enable web-based self-checkout (SelfCheckoutByLogin or IP-range). 2. Log in as a patron at /cgi-bin/koha/sco/sco-main.pl. 3. Open browser DevTools -> Application -> Cookies. Note the JWT cookie value. 4. Click the green "Finish" button. 5. Without the patch: observe Set-Cookie: JWT= on the ?op=logout response with no Expires; the JWT cookie may persist or be replaced with an empty session cookie that some browsers/proxies handle inconsistently. 6. Apply the patch and reload. Click Finish again. 7. Confirm Set-Cookie: JWT=; expires=<past>; ... is sent and the JWT cookie is removed from the browser entirely. 8. Confirm the kiosk reliably returns to the login screen and the next page load does not re-authenticate from a stale JWT. Sponsored-by: OpenFifth (Ticket #246176, John Innes Centre) -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 41604] New: Impossible to hide Checkin column in issues-table in circ/circulation.pl
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41604 Bug ID: 41604 Summary: Impossible to hide Checkin column in issues-table in circ/circulation.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 41314 caused a regression, making it impossible to hide the Checkin column in the issues table in the patron's circulation page. We had complaints about this following our first wave of upgrades from 24.05(.05) to 25.05(.06). To recreate: 1. Hide the checkin column by default in circulation issues-table 1.1. Go to Administration > Table settings > Circulation tab > Jump to page : circulation > Table id: issues-table 1.2. Check "Is hidden by default" for "checkin" 1.3. Click "Save" 2. Checkout an item to a patron 2.1. In the search bar, set to Checkout, search for Henry 2.2. In the checkout field, enter the barcode 39999000010114 and press enter --> In the table of issues, Checkin column is visible, it should be hidden by default I personally find the checkin column particularly dangerous as staff don't need to scan the item to return it, leading to potentially checking in items that weren't actually returned by the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 176

[Bug 17748] New: Show due date and availability in item search results
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17748 Bug ID: 17748 Summary: Show due date and availability in item search results Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com After searching an item, i. e. with barcode, you can't see wheter it is checked out or not. Therefore the due date and / or the availability of the item would be very helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 39224] New: Move Shibboleth config from koha-conf to the DB
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39224 Bug ID: 39224 Summary: Move Shibboleth config from koha-conf to the DB Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: jacob.omara(a)ptfs-europe.com Reporter: jacob.omara(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 38201 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38201 [Bug 38201] VueJS architecture rethink -- You are receiving this mail because: You are watching all bug changes.

1 158

[Bug 31606] New: Enhance acquisitions to allow ordering on next year's budget when still in current year.
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '26

06 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31606 Bug ID: 31606 Summary: Enhance acquisitions to allow ordering on next year's budget when still in current year. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 140860 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140860&action=e… Full description of problem of end-of-year processing & possible solution. The topic of end-of-year processing has come up regularly in the koha-us Acquisitions SIG. Librarians would like to have a way to order things for the next year when still in the current year and have the items showing up on the next year's budget. Example: our library has a fiscal year that goes from Oct 1 to Sept 30. A popular book will release October 15. We want to order the book in August. We would like to have the item ordered on the new fiscal year starting October. How do we do that? I have attached a Word document that more fully explains the issue and I have suggested a solution that I think will work for both EDI and non-EDI vendors. Please look over the solution and share any problems or improvements. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 61