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

[Bug 43523] New: cleanborrowers.pl is slow
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43523 Bug ID: 43523 Summary: cleanborrowers.pl is slow 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I have been looking at cleanborrowers.pl and find that it can be slow when dealing with many borrowers. I have identified some areas where I think improvements can be easily made. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 43460] New: REST API XML payload conversion breaks plugin API routes that consume XML
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43460 Bug ID: 43460 Summary: REST API XML payload conversion breaks plugin API routes that consume XML Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com Target Milestone: --- Bug 37762 makes the REST API convert request bodies sent with an application/xml content type to JSON so they can be validated against Koha's swagger definitions, and convert response bodies with an application/xml content type from JSON to XML. Both hooks apply to every route, including the /contrib plugin routes. Plugins define their own API contracts and may read and output XML directly. For example, the POC for the NCIP server plugin accepts XML messages on its route. On Koha 26.05 and later the request hook replaces the incoming NCIP message with a JSON rendering of it before the plugin controller runs, destroying the message such that element attributes and ordering are lost with no way to get to that data. The response hook then dies trying to parse the plugin's XML response as JSON, turning it into a 500. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 39419] New: Holds API treats 'expiration_date' as 'patron_expiration_date'
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39419 Bug ID: 39419 Summary: Holds API treats 'expiration_date' as 'patron_expiration_date' 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is going to have a related issue in Aspen, but I think the confusion starts here Koha has two fields for hold expiration: expirationdate - (usually) auto generated date set based no when holds on the shelf expire patron_exiration_date - the day the patron says they don't need the hold after The API takes "expiration_date" and maps it to "patron_expiration_date" This can be unclear for outside systems. Aspen has a 'Default Not Needed After Days' setting which is assumed to be setting the automatic expiraton date, but in fact sets the patron date We should allow either field to be set via the API -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 108

[Bug 42039] New: Properly set LDR/5 for deleted bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42039 Bug ID: 42039 Summary: Properly set LDR/5 for deleted bibliographic records Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org For deleted authority records we automatically set LDR/5 to 'd' (cf. https://www.loc.gov/marc/authority/adleader.html) The same should be done for bibliographic records: "System-Generated Elements - Following Leader elements are usually system generated: [...] 05 Record status" (cf. https://www.loc.gov/marc/bibliographic/bdleader.html) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 33153] New: Bibliographic references disappear from the payment history if the item is deleted
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33153 Bug ID: 33153 Summary: Bibliographic references disappear from the payment history if the item is deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When you create a payment for a user, if you specify the reference of an item, Koha keeps track of the item and the record in the payment history. But if the item is deleted after the payment is done, this information disappears from payment history. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 39418] New: RDA Carrier, Content, & Media Vocabularies
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39418 Bug ID: 39418 Summary: RDA Carrier, Content, & Media Vocabularies Change sponsored?: --- 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: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On our Koha, we've loaded the RDA vocabularies for MARC 336 Content, 337 Media, and 338 Carrier into our authorized values in order to connect them with the $a and $b subfields of those fields in our MARC frameworks. This bug would preload these vocabularies for new instances of Koha. There are two AV categories per field, one for the human-readable term ($a) and one for a short code ($b). I made the lib/lib_opac text for the codes the term they represent, so one does not have to memorize the meanings of the codes. I do not see any instance of an authorized value being connected with a MARC field during installation (looking in installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml where all the authorised_value properties are empty) so I have not done so with these either. That seems reasonable; some libraries may want to use different terms. But the RDA vocabs are widely used and stable, so including them as an option for catalogers is worthwhile. To load these into an existing Koha instance, this is the SQL we used: https://github.com/phette23/scrape_rda_vocabs/blob/main/koha.sql -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 34597] New: Expired patrons can still place ILL requests through OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34597 Bug ID: 34597 Summary: Expired patrons can still place ILL requests through OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, magnus(a)libriotech.no, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Noticed this, not sure if very severe or not. But I wonder if placing an ILL request should be included in BlockExpiredPatronOpacActions. To reproduce, on k-t-d: 1) Enable ILLmodule and install FreeForm, run: bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Make koha/koha user expired, run mysql-kohadev: update borrowers set dateexpiry = '2020-12-31' where borrowernumber=51; 3) Visit OPAC/cgi-bin/koha/opac-user.pl and verify there's a user expired notification 4) Visit OPAC/cgi-bin/koha/opac-illrequests.pl and create a new ILL request 5) It's created with no issue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53

[Bug 25465] New: Batch delete records based on imported MARC batch
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25465 Bug ID: 25465 Summary: Batch delete records based on imported MARC batch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Various vendors send libraries batches of MARC records for deletion -- these are records the library already has in their system that should be deleted as the vendor no longer offers them. Right now we can: - stage the batch for import using a matching rule - run a report to return matched biblionumbers - batch delete based on the report output It'd be great to streamline this. My two thoughts are either we could add a new option to batch record deletion to allow use of an imported file to identify records OR we could add a new matching behavior of "delete matched record" to the batch staging tool. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43709] New: Cataloging: intermittent 400/403 error when switching MARC framework in the basic editor (addbiblio.pl)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43709 Bug ID: 43709 Summary: Cataloging: intermittent 400/403 error when switching MARC framework in the basic editor (addbiblio.pl) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- In the basic MARC editor (cataloguing/addbiblio.pl), switching the framework from the "Settings" dropdown (.change-framework links) intermittently fails with a 400 or 403 error instead of reloading the form with the new framework. The failure is frequent but not systematic. Two independent causes combine to produce this: 1. Missing e.preventDefault() on the .change-framework click handler. Changefwk() submits the form via POST, but the triggering link (href="#") is never cancelled. Depending on browser/timing, the hash navigation can race with the form submit, and the server can end up receiving a GET request instead of POST. The CSRF middleware rejects any GET request carrying op=cud-* => 400. 2. CSRF token invalidated by browser bfcache. The CSRF token (Koha::Token, see _add_default_csrf_params in Koha/Token.pm) is tied to userid + '_' + session_id. If the session changes while the page is open (session expiry followed by a new session, logout in another tab, or external session cleanup) and the browser serves the page from bfcache with the old embedded token, validation fails => 403. addbiblio.pl's Cache-Control: no-cache (without no-store) does not prevent bfcache from serving the page. Steps to reproduce (#2, the more reliably reproducible of the two): 1. Open the basic MARC editor for a record (cataloguing/addbiblio.pl) in a tab. 2. In another tab, log out, or let the session expire, or otherwise invalidate the current session (e.g. restart Plack / clear sessions table). 3. Navigate away from the editor tab and back (browser back/forward, or close and reopen via history) so it is served from bfcache with the stale CSRF token still embedded. 4. Use "Settings" > switch framework. The request fails with 403 (or the page behaves as if nothing happened, depending on how the browser renders the cached state). #1 is timing/browser-dependent and harder to force deterministically from the UI; it was identified by code audit of the click handler (.change-framework lacks preventDefault while the <a href="#"> stays a live navigation target). Proposed fix (4 independent, complementary changes): 1. addbiblio.tt: add e.preventDefault() to the .change-framework click handler, so the href="#" navigation never competes with the POST submit. 2. addbiblio.tt: store the page's CGISESSID cookie value on load; before submitting via Changefwk(), compare it to the current cookie and reload the page instead of submitting if it changed. 3. addbiblio.tt: add a 'pageshow' listener that reloads the page when event.persisted is true (page served from bfcache), so a stale CSRF token is never submitted. 4. addbiblio.pl: pass { force_no_caching => 1 } to both output_html_with_http_headers calls, adding Cache-Control: no-store so the page is excluded from bfcache in browsers that honor it. Bug 37745 and Bug 34478 fixed earlier problems with the framework switch (duplicated CSS class, missing CSRF token), but these two issues were not caught by either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 43229] New: Purchase suggestions incorrectly promises an email confirmation for anonymous suggestions
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43229 Bug ID: 43229 Summary: Purchase suggestions incorrectly promises an email confirmation for anonymous suggestions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- 1. Enable preference suggestion 2. Enable preference AnonSuggestions 3. Navigate to OPACBaseURL/cgi-bin/koha/opac-suggestions.pl?op=add_form (make sure you are not logged in) 4. Click "+ New purchase suggestion" 5. Observe text "You will receive an email when the library processes your suggestion." -- You are receiving this mail because: You are watching all bug changes.

1 22