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

[Bug 39208] New: printoverdues.sh requires unavailable cli tool
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39208 Bug ID: 39208 Summary: printoverdues.sh requires unavailable cli tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz `printoverdues.sh` relies on `xhtml2pdf` for the conversion of a HTML document to a printable PDF version of said document. At time of writing, this tool dropped out of Debian (bookworm) and Ubuntu stable and sometimes older releases including backports and the like. Debian oldstable still keeps it, but no upstream releases beyond. This may endanger the functionality in Koha upstream. Possible solutions: - Manual installation outside the package management (and bugfixing) of the distribution via `pip`. That would also require a suitable documentation. - Use an alternative tool chain within the distributions (e.g. pandoc, if heading for a swiss army knife of format transformations. For PDF pandoc would require latex as "helper"). Note that `printoverdues.sh` is referred to explicitly in the implementation checklist. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 35246] New: REST API: api/v1/biblios crashes with accept header application/json
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35246 Bug ID: 35246 Summary: REST API: api/v1/biblios crashes with accept header application/json Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: tomascohen(a)gmail.com See also bug 33960. Found it testing there. [2023/11/03 10:33:00] [ERROR] GET /api/v1/biblios: unhandled exception (Mojo::Exception)<<Can't call method "to_api" on an undefined value at /usr/share/koha/Koha/Biblio.pm line 1433.>> => my $json_biblioitem = $self->biblioitem->to_api( $args ); Just testing /api/v1/biblios with Accept=application/json. Note that Accept=application/marc works fine. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 42579] New: Checkout history export "title" column too long
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42579 Bug ID: 42579 Summary: Checkout history export "title" column too long 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: chris.mathevet(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org In OPAC, if you export to CSV or copy to clipboard your checkout history. Title column contains rating informations with extra spaces. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 40610] New: Update OPAC templates to improve east of translation
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40610 Bug ID: 40610 Summary: Update OPAC templates to improve east of translation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com Looking at [lang]-opac-bootstrap.po I see a lot of instances of repeated %s %s %s indicating opportunities to improve the markup structure to ease the translation process. This patch will tackle a batch of include files: koha-tmpl/intranet-tmpl/prog/en/includes/item-status.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title-head.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/biblio-title.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/date-format.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/holds-table.inc koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 42505] New: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Bug ID: 42505 Summary: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When returning an item required to fulfil a hold at another branch, with HoldsAutoFill set to 'Don't', the 'Hold found' modal (returns.tt: hold-found-modal / hold-found2 in older versions) is displayed and the librarian must choose 'Confirm hold and transfer' or 'Print slip, transfer, and confirm'. If the librarian clicks the print variant, the slip is opened via window.open() (Dopop()) called from $(document).ready on the page that loads *after* the form submission to confirm the hold. Because the window.open() call happens during a fresh page load, it is not associated with a user gesture, and modern browsers block it as an unsolicited popup. This affects the same code path used for HoldsAutoFill + HoldsAutoFillPrintSlip: the slip popup is fired on document.ready of the response page, with the same popup-blocker risk. Steps to reproduce ================== 1. Set HoldsAutoFill = Don't. 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. The 'Hold found' modal appears. 5. Click 'Print slip, transfer, and confirm'. Expected: the hold is confirmed and the hold transfer slip opens in a new window. Actual: the form submits and the hold is confirmed, but the slip popup is blocked by the browser. The librarian sees no slip and may not realise the slip was attempted. Root cause ========== In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print click handler sets a hidden input print_slip=1 and submits the form. The server (circ/returns.pl) sets the print_slip template parameter on the response, and the response page calls Dopop() (window.open) on document.ready. That window.open() is not within a user gesture event, so popup blockers reject it. Suggested fix ============= Open the print window synchronously inside the .print click handler, while the user gesture is still active. The reserve_id is already present in the modal form as a hidden input, and hold-transfer-slip.pl needs only the reserve_id; the slip content does not depend on the hold having been moved to Waiting state. The form submit to confirm the hold then proceeds in the main window as before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 42608] New: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Bug ID: 42608 Summary: Hold-shelf expiration over-extends when ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode=Dayweek Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When ExcludeHolidaysFromMaxPickUpDelay is on and useDaysMode is set to Dayweek, the pickup expiration date set for a hold by Koha::Hold::set_waiting is inflated by a whole week whenever the pickup window crosses a single (one-off) closure on a normally-open weekday -- for example a Bank Holiday Monday. Steps to reproduce ================== System preferences: ReservesMaxPickUpDelay = 6 ExcludeHolidaysFromMaxPickUpDelay = ON ExpireReservesOnHolidays = ON useDaysMode = Dayweek Branch calendar: - Sundays marked as a weekly closed day. - A single (one-off) holiday on a Monday two weeks out -- for example 2026-05-04 (the early May Bank Holiday). Trap a hold to waiting at that branch on Tuesday 2026-04-28. Actual result ============= expirationdate is set to 2026-05-12 -- a 14-day pickup window. Expected result =============== expirationdate should be 2026-05-06 -- a 6-open-day pickup window. The intent of ExcludeHolidaysFromMaxPickUpDelay is to give the patron the full ReservesMaxPickUpDelay count of *open* days to come and collect the item, by extending the window by one calendar day for every closed day that falls inside it. useDaysMode (Dayweek / Datedue / Calendar / Days) is a loan-due-date concept -- the patron picks no weekday for a hold pickup; staff trap the item, and the only thing that should influence the expiration date is how many open days the patron should get to collect. Wider example table =================== Same configuration as above. Sunday 3 May and Monday 4 May 2026 are closed at the branch. Comparison of current (buggy) vs expected expiration dates for each weekday a hold could be trapped that week: Hold trapped on Current (buggy) Expected ----------------- ----------------- ----------------- Mon 27 Apr 2026 Mon 11 May 2026 Tue 5 May 2026 Tue 28 Apr 2026 Tue 12 May 2026 Wed 6 May 2026 Wed 29 Apr 2026 Wed 13 May 2026 Thu 7 May 2026 Thu 30 Apr 2026 Thu 14 May 2026 Fri 8 May 2026 Fri 1 May 2026 Fri 15 May 2026 Sat 9 May 2026 In each case the expected expiration is `waitingdate + ReservesMaxPickUpDelay` open days, with Sun 3 May and Mon 4 May skipped (not counted toward the 6-day window). The current buggy expirations are all 14 calendar days from the trap date -- a whole extra week. Reproduction snippet ==================== use Koha::Calendar; use Koha::DateUtils qw(dt_from_string); # Test branch: Sundays weekly closed, single holiday 2026-05-04. my $cal = Koha::Calendar->new( branchcode => 'BR', days_mode => 'Dayweek', ); # Bug: prints 2026-05-12 (14 days). # Expected: 2026-05-06 (6 open days). say $cal->days_forward( dt_from_string('2026-04-28'), 6 )->ymd; Notes ===== Loan due dates calculated by Koha::Calendar::addDays under useDaysMode=Dayweek behave correctly -- the bug only surfaces on hold pickup expiration dates. A fix should not regress the loan due-date behaviour, which is the original purpose of the Dayweek mode (keeping a Friday-due loan due on a Friday over closures). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 42667] New: Split the ability to edit other librarian's reports into a separate permission
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42667 Bug ID: 42667 Summary: Split the ability to edit other librarian's reports into a separate permission Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com My work on bug 42108 has lead me to realize that being able to edit anyone's reports creates a loophole that allows anyone who can create reports to bypass 42108 by simply editing someone else's existing report. Aside from that, this seems like a good idea in general. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 41297] New: Add duplicate invoice number detection on EDI invoice import
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41297 Bug ID: 41297 Summary: Add duplicate invoice number detection on EDI invoice import Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org EDIFACT invoice processing should detect and block duplicate invoice numbers, notify the supplier (possibly via an EDI CONTRL message), and alert library staff. While Koha has the AcqWarnOnDuplicateInvoice system preference for manual invoice creation (implemented in Bug 10366), this check is not applied to invoices created automatically via EDIFACT/EDI processing in Koha/EDI.pm. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[Bug 38589] New: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38589 Bug ID: 38589 Summary: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de In the manual, the item bundle section (https://koha-community.org/manual/latest/fr/html/circulation.html#circulati…) states "The bundle functionality will only be displayed if you create a catalogue record with the Leader, (000 MARC tag) position 7 set to ‘c’ for Collection." and displays a picture from MARC21 framework This exact configuration setting is working for UNIMARC ("c" in pos.7 of leader), but this is not obvious as many settings in Koha are MARC-flavour-dependant -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31925] New: AutoCreateAuthorities needs to preserve subject heading thesaurus to not create duplicate authority records
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31925 Bug ID: 31925 Summary: AutoCreateAuthorities needs to preserve subject heading thesaurus to not create duplicate authority records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: nick(a)bywatersolutions.com Depends on: 30280 Bug 30280 taught the linker that "650 _ 0 $aFeminism" and "650 _ 7 $aFeminism$2sao" are not the same heading, so a bib record containing the latter should not be linked to the authority record which matches the former. However, AutoCreateAuthorities just creates LCSH authority records from anything, no matter what the values of indicator 2 and subfield 2 are. As a result, if you have an LCSH authority record for a term, and you import/create a non-LCSH term in a bib record and save it, AutoCreateAuthorities will create a new duplicate LCSH authority record and link to that. Every single time, a new duplicate. Steps to reproduce: 1. Use ElasticSearch, since the patch for bug 30280 only expected to work there, and in fact broke linking on Zebra, bug 31924. 2. Enable the preferences AutoCreateAuthorities, AutoLinkBiblios, CatalogModuleRelink 3. Edit any bib record, add a 650 tag, set the second indicator to 7, type Feminism in subfield a and type sao in subfield 2. 4. Save the record, edit it again, note the authority record id in subfield 9 of the Feminism heading. 5. Edit any other bib record, add a 650 tag, set the second indicator to 7, type Feminism in subfield a and type sao in subfield 2. 6. Save the record, edit it again, note the authority record id in subfield 9 of the Feminism heading. The two authority record ids should be the same, since the headings are identical, but instead one will be linked to, say, 1708 and the next to 1709, an identical duplicate record. Rather than setting position 11 of field 008 in the authority record to "a" for LCSH, AutoCreateAuthorities should have set it to "z" for Other and put sao in subfield f of field 040 (and for non-7, non-0 values of indicator 2, it should be setting 008/11 to the correct letter for that indicator value). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280 [Bug 30280] Support authority records with common subject headings from different thesaurus -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 84