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

[Bug 43226] New: Change AUTO_RENEWAL and AUTO_RENEWAL_DGST to AUTO_RENEWALS and AUTO_RENEWALS_DGST
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43226 Bug ID: 43226 Summary: Change AUTO_RENEWAL and AUTO_RENEWAL_DGST to AUTO_RENEWALS and AUTO_RENEWALS_DGST Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation 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: aude.charillon(a)openfifth.co.uk, david(a)davidnind.com, philip.orr(a)lmscloud.de Target Milestone: --- The manual has the code AUTO_RENEWAL and AUTO_RENEWAL_DGST (renewal singular), but the letter codes in Koha are plural AUTO_RENEWALS and AUTO_RENEWALS_DGST. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 31630] New: Batch item deletion no longer shows which items were not removed
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31630 Bug ID: 31630 Summary: Batch item deletion no longer shows which items were not removed Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lnilsson(a)lewistonschools.net QA Contact: testopia(a)bugs.koha-community.org The only warning > given is an unclicked box and when deleting long lists it is hard to notice. > The follow up page use to have a notification stating some barcodes were not > deleted, please help. Thanks, LeeAnn Same problem I had with closed Bug 28353 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42952] New: Public SRU with OPAC logic out-of-the-box
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '26

15 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42952 Bug ID: 42952 Summary: Public SRU with OPAC logic out-of-the-box Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers 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 Target Milestone: --- While working with Terry Reese to fix the MarcEdit integration with Koha, he pointed out that Koha doesn't have a public Z39.50/SRU endpoint out of the box. I think the reasoning previously has been that the z3950responder.pl and Zebra provide unfiltered access to the indexes. But... with the z3950responder.pl we could provide a more mediated access. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 43816] New: 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge don't block at the same threshold
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43816 Bug ID: 43816 Summary: 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge don't block at the same threshold Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Target Milestone: --- With the new OPAC account self-renewal feature (bug 26355), patrons can be prevented from self-renewing if they owe more than a certain amount on their account. The amount is set by the following, in this order: 1) 'Self-renewal charge limit' in the Account expiry and self-renewal section of patron category settings - if blank, then 2) 'Checkout charge limit' in patron category settings - if blank, then 3) noissuescharge system preference However, patrons are blocked from self-renewal if they owe *equal to or greater than* the amount in 'Self-renewal charge limit', but only if *greater than* the amount in 'Checkout charge limit' and noissuescharge. This should be consistent so that they all either block at equal to or greater than the amount, or only when someone owes more than the amount set in any of the three. To recreate: -Create a $10 manual charge on a test patron's account -Set their account to expire tomorrow -Set their patron category to allow self-renewal with a 'Self-renewal availability period' of 5 -Set 'Self-renewal charge limit', 'Checkout charge limit', and noissuescharge to 10 -Log into the OPAC as the test patron, and note that there is no link to self-renew -Return to the patron category, and clear the value in 'Self-renewal charge limit' (leave 'Checkout charge limit' and noissuescharge at 10) -Return to the OPAC, refresh, and see that the link to self-renew appears -In the patron category, clear the value in 'Checkout charge limit' (leave noissuescharge at 10, and 'Self-renewal charge limit' blank) -In the OPAC, refresh again, and see that the link to self-renew is still available Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 43269] New: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43269 Bug ID: 43269 Summary: Add cached description_for() class methods to Koha::Libraries, Koha::ItemTypes, Koha::Patron::Categories Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Several places in Koha need to resolve codes to human-readable descriptions (branchcode to library name, categorycode to category description, itype to item type description). Currently this is done either per-row via Koha::Libraries->find($code)->branchname (uncached, N+1 queries) or via C4::Biblio::GetAuthorisedValueDesc (cached but MARC-centric API requiring tag/subfield/framework). We should add cached class-level lookup methods on the domain objects: Koha::Libraries->name_for($branchcode); Koha::Patron::Categories->description_for($categorycode); Koha::ItemTypes->description_for($itype); These would: - Use Koha::Caches to pre-fetch all values for the table on first access - Return the description string (or the raw code as fallback) - Be usable from any context (CSV exports, templates, scripts, REST API) This decouples the caching from the MARC layer and makes it available to the Koha::CSV subclass pattern (bug 41621) and anywhere else that needs bulk code-to-description resolution without N+1 queries. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 43815] New: More granular options for Can Be Guarantee
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43815 Bug ID: 43815 Summary: More granular options for Can Be Guarantee Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- As Bug 37439 notes, the ChildNeedsGuarantor preference is actually much more sweeping in its implications, catching both Child-type accounts (legacy mechanism for guarantee relationship) with patron categories set to 'Can be guarantee.' This rolls back the flexibility granted to make any patron category guarantee-able to reflect the diverse communities libraries serve, if a library would otherwise like to have require responsible adult patrons for children's accounts. It would be nice if the 'Can be guarantee' designation had options for 'Must have guarantor' and 'May have guarantor' so that libraries can configure genuine child accounts to have adult account holder while still allowing a library to honor adult guardianship situations. Without something like this, ChildNeedsGuarantor is largely too restrictive for many public library systems. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43814] New: Make account renewal success message customizable
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43814 Bug ID: 43814 Summary: Make account renewal success message customizable Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 26355 Target Milestone: --- The new OPAC self-renewal option (Bug 26355) has a customizable failure message with the field 'Self-renewal failure message', but the success message isn't similarly customizable in patron category settings. It would be helpful if the success message could be customized as well. It defaults to 'Your account has been successfully renewed until [date per patron category]. You should receive a confirmation shortly.', but that will be confusing for patrons whose libraries aren't sending any sort of confirmation message. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26355 [Bug 26355] Allow patron account renewals through the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37248] New: [Omnibus] Power to the user
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37248 Bug ID: 37248 Summary: [Omnibus] Power to the user Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This is for the initiative for helping to ensure that users can do as much of the configuration in the interface rather than the command line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43812] New: ILL requests on detail.pl should honor ILLHiddenRequestStatuses
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43812 Bug ID: 43812 Summary: ILL requests on detail.pl should honor ILLHiddenRequestStatuses Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- On detail.pl any ILL request associated with the biblio are displayed on the record detail page: # Check if there are any ILL requests connected to the biblio my $illrequests = C4::Context->preference('ILLModule') ? Koha::ILL::Requests->search( { biblio_id => $biblionumber } ) : []; $template->param( illrequests => $illrequests ); This should honor ILLHiddenRequestStatuses -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 43805] New: Logging back in after a session timeout 404s on Vue pages served through a RewriteRule (record_sources, circulation_triggers)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '26

14 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43805 Bug ID: 43805 Summary: Logging back in after a session timeout 404s on Vue pages served through a RewriteRule (record_sources, circulation_triggers) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Staff interface pages that are served through a RewriteRule of the form RewriteRule ^/cgi-bin/koha/admin/record_sources(.*)?$ /cgi-bin/koha/admin/record_sources.pl$1 [PT] (etc/koha-httpd.conf and debian/templates/apache-shared-intranet.conf; the same shape is used for admin/circulation_triggers) cannot be logged back in to after the session times out. The pattern also matches the script's own name, so a request for record_sources.pl is rewritten to record_sources.pl.pl and returns 404. When the login form is shown on such a page, its action is the script name (/cgi-bin/koha/admin/record_sources.pl). Submitting it therefore 404s, no session is created, and the user is stuck on an error page until they log in through another page (for example mainpage.pl) and navigate back. To reproduce (main, 26.06.00.035, in KTD): 1. Log out (or let the session expire). 2. Open /cgi-bin/koha/admin/record_sources. The login page is shown; its form action is /cgi-bin/koha/admin/record_sources.pl. 3. Enter valid credentials and submit. Expected: you are logged in and see the record sources page. Actual: "Error 404 > Koha". No session is created. Evidence with curl (cookie jar, valid csrf_token taken from the login page): - POST to the form action /cgi-bin/koha/admin/record_sources.pl -> 404 - POST of the same fields to /cgi-bin/koha/admin/record_sources -> 200 GET /cgi-bin/koha/admin/record_sources.pl and /cgi-bin/koha/admin/circulation_triggers.pl also return 404. Not affected: acquisition/vendors, whose rule maps acquisition/vendors to acqui/vendors.pl, so acqui/vendors.pl is reachable (200). Found while building a new Vue page under Cataloguing (bug 30800), which copies the same rule and so has the same problem. Possible directions (not verified): - Guard the rules so the script's own name is not rewritten, as is already done for preservation in the same file: RewriteCond %{REQUEST_URI} !^/cgi-bin/koha/preservation/.*.pl$ A similar RewriteCond for each of these pages would let the .pl URL reach the script. The Vue router base paths are the extensionless URLs, so it needs checking what the app does when it is loaded on the .pl URL after login. - Or have the login form post back to the URL the user actually requested instead of the script name when the request was rewritten. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5