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

[Bug 43568] New: Add ability to user a specific SMTP server for Email to SMS feature
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43568 Bug ID: 43568 Summary: Add ability to user a specific SMTP server for Email to SMS feature Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Target Milestone: --- There are places that offer their own Email to SMS service ( https://www.oplin.ohio.gov/sms is the one I'm aware of ). If a library wants to use such a service right now, it means all email must go through this email service. It would be good and useful to be able to specify a single SMTP server for Email to SMS to use specifically with all other email going through the standard channels. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[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 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 41162] New: Warn that printing large barcode ranges can lead to running out of memory
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41162 Bug ID: 41162 Summary: Warn that printing large barcode ranges can lead to running out of memory Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.orr(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org If you are using the barcode range option in the label creator, if your barcode range is too large, your Koha server may run out of memory before the process finishes. This causes out of memory errors. This could happen if a library had e.g. "100101223" as their last used barcode and they wanted to print the next 50 barcodes and they make a mistake while entering the "To:" field in the barcode range creator. From: 100101224 To: 1000101274 You could very easily accidentally cause the label-create.pl process to create insane amounts of barcodes. In this case 900 million barcodes would be created, if my math is right. :) The memory usage will slowly increase as barcodes are created and "eventually" there will be no more memory left, causing OOM killer to strike. We should at least warn in the barcode range creation tool that such problems can happen if you aren't careful while entering values. I don't know if there's a good way to stop users from entering too large ranges, maybe there is a valid use case for a large barcode range if you have enough memory. To reproduce (assuming you are on ktd): 1. Check your current memory usage, e.g. with "ps aux --sort -rss" (or "free -h" to see how much memory is still free) 2. Make sure you know how to kill a process in Debian, e.g. "killall -9 /kohadevbox/koha/labels/label-create-pdf.pl" - you will need it soon.. 3. Go to Cataloging -> Label Creator -> Print barcode range 4. Enter in a number in "From:" and a crazy high number in "To:"; see above for an example 5. Print range -> Export (doesn't matter which templates etc.) -> Click on "Download as PDF" 5. Check your memory usage again, it should start spiking over the next minutes. The guilty process should be /kohadevbox/koha/labels/label-create-pdf.pl (assuming you are on ktd). 6. Either kill the process or you will run out of memory -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43791] New: Action's column in item types table
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43791 Bug ID: 43791 Summary: Action's column in item types table Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Hi, In 26.05 version of Koha, the Actions column in the document types table in the admin module is no longer visible by default. You have to adjust the column display to show it. This wasn’t the case before this version. Also, this column is not adjustable in the table_item_type configuration, so you can't set it up. Since it contains both the button to edit and delete a document type, it would be nice if this column was always shown by default. Regards. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_26_11_candidate -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #36 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Passing QA. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '26

13 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 --- Comment #35 from Ray Delahunty <raymund.delahunty(a)outlook.com> --- Test plan point 7 puzzled me until I noticed that the diff column in logviewer is hidden be default. Once I exposed it, the before and after data appeared. I am obviously rusty signing off bugs! -- You are receiving this mail because: You are watching all bug changes.

1 0