August 2025 - Koha-bugs - lists.koha-community.org

[Bug 39896] New: Syspref AuthorLinkSortBy is not working for Unimarc or custom XSLT
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39896 Bug ID: 39896 Summary: Syspref AuthorLinkSortBy is not working for Unimarc or custom XSLT Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The syspref AuthorLinkSortBy and AuthorLinkSortOrder depend on code in XSLT files. Currently, the code is only present in the default MARC21 files but it is not present in any UNIMARC files. Plus, if a library uses customs XSLT files (with syspref OPACXSLTDetailsDisplay, OPACXSLTResultsDisplay, XSLTDetailsDisplay, or XSLTResultsDisplay) they will not be able to use this functionality (unless they also updated their files but they have no way to know they need to do that). This is inevitable and is okay, but I think we should mention somewhere that these syspref depend on XSLT. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 40304] New: Zebrasrv config doesn't consider non-AMD64 CPUs
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40304 Bug ID: 40304 Summary: Zebrasrv config doesn't consider non-AMD64 CPUs Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Hi folks, As per this Mattermost conversation: https://chat.koha-community.org/koha-community/pl/ft6e47akutn6fbdg5tpwab5zbw I've identified an issue where running t/db_dependent/Search.t fails on AARCH64 machines. Upon investigation, I've found that in the default zebra-biblios-dom.cfg and zebra-authorities-dom.cfg files, the module search path does not include as many architectures as it should. I have rectified this, by copying the lines found in the debian/templates folder to the relevant config files mentioned in the last paragraph. Could I ask someone to check the patch I'm about to push, so we can get a quick conclusion to this bug? Ta, Jake -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 32950] New: marc modification template moving subfield can lose values for repeatable fields
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32950 Bug ID: 32950 Summary: marc modification template moving subfield can lose values for repeatable fields Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 146586 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=146586&action=e… mrc with multiple 020 fields including 020$z Moving one subfield to another fails for repeatable fields where the field to be moved doesn't exist in the first instance 1. Make marcmodtemplate as follows a. Move every 020 z field to field 020 a 2. Stage marc exchange file (attached) with following in 020 field (note only 7th and 8th have 020z and these are the ones we wish to move to subfield a) =020 \\$a9781003182870$q(ebk) =020 \\$a1003182879 =020 \\$a9781000407204$q(electronic bk. : EPUB) =020 \\$a1000407209$q(electronic bk. : EPUB) =020 \\$a9781000407167$q(electronic bk. : PDF) =020 \\$a1000407160$q(electronic bk. : PDF) =020 \\$z9781032023175$q(hbk.) =020 \\$z9780367760380$q(pbk.) 3. view staged record and observe fields 020 subfield a fields have all gone and subfield z has not been moved, but its value removed: 020 _a _q(ebk) 020 _a 020 _a _q(electronic bk. : EPUB) 020 _a _q(electronic bk. : EPUB) 020 _a _q(electronic bk. : PDF) 020 _a _q(electronic bk. : PDF) 020 _q(hbk.) _a 020 _q(pbk.) _a Note, adding a conditional to marcmodtemplate "only do this if 020 z subfield exists makes no difference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 39408] New: Cannot add patron via API if AutoEmailNewUser and WELCOME content blank
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39408 Bug ID: 39408 Summary: Cannot add patron via API if AutoEmailNewUser and WELCOME content blank Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Some libraries use Template Toolkit logic to avoid sending emails. In the case of the welcome notice they may only want to send for patrons fully added, not self registered. In the case of Aspen, we currently use the patrons API for self registration as there is not a self registration API. If you add logic like: [% USE Koha %] [% IF borrower.categorycode != 'SELFREG' %] Hello [% borrower.title %] [% borrower.firstname %] [% borrower.surname %]. Thank you for joining [% IF Koha.Preference('LibraryName') %][% Koha.Preference('LibraryName') %][% ELSE %]the library[% END %] You can search for all our materials in our <a href='[% Koha.Preference('OPACBaseURL') %]'>catalog</a>. Your library card number is [% borrower.cardnumber %] If you have any problems or questions regarding your account, please contact the library. [% END %] Then add a patron via the API in the self reg class: {"surname":"PATRON","firstname":"PROBLEM","library_id":"CPL","category_id":"SELFREG","email":"eample(a)example.org"} You get an error response: "Given does not exist" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 40515] New: Mark as lost and notify patron is broken in pendingreserves.pl
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40515 Bug ID: 40515 Summary: Mark as lost and notify patron is broken in pendingreserves.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Steps to reproduce: 1 - Have a new reserve for an available item. 2 - Go on "Holds to pull" 3 - Click on the button "Mark as lost and notify patron" -> Nothing happens -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 37926] New: Bookings - "to" untranslatable
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37926 Bug ID: 37926 Summary: Bookings - "to" untranslatable Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com When placing a booking, where we choose the dates of the booking, the "to" between the two dates is not translatable. To get there: 1. In a detailed record, click on the Items tab on the left 2. Where it says Bookable, choose Yes and click Update 3. Click Place booking 4. Find and select a patron to enable the other fields 5. Under Booking dates, choose two dates --> Dates are displayed as date1 to date2 6. Translate the interface gulp po:update --lang fr-CA ./misc/translator/translate update fr-CA 7. In the system preference StaffInterfaceLanguage, select the other language and click Save all I18N/L10N preferences 8. Change the interface in the other language 9. Redo steps 3 to 5 --> Dates are still displayed as date1 to date2 I searched the various po files, but I didn't take the time to check all occurrences of "to", obviously. I mostly searched for "%s to %s" and modals/place_booking.inc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 40473] New: X scale for Code39 barcodes is calculated incorrectly
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40473 Bug ID: 40473 Summary: X scale for Code39 barcodes is calculated incorrectly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org While reviewing how "Barcode width" works as added by bug 10762, I noticed that the calculation of the X scale factor for Code39 barcodes is incorrect. If you specify a Barcode width of 1, you'd expect that to use 100% of the label width. But it doesn't. Now this isn't a problem introduced by Bug 10762, because Bug 10762 just replaced a hard-coded value of .8 with a editable value. It's a much older bug. Consider the following: $x_scale_factor = ( $params{'width'} / $tot_bar_length ); $params{'width'} is the "Barcode width" multiplied by the label width. This makes sense as it represents the total width that we're willing to use. The problem is $tot_bar_length. It uses an algorithm which is inconsistent with the algorithm used by PDF::Reuse::Barcode. But that's easy to fix! -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 40470] New: REPORT_GROUP authorized value cannot be numeric
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40470 Bug ID: 40470 Summary: REPORT_GROUP authorized value cannot be numeric Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com If you create a REPORT_GROUP authorized value with a purely numeric value, the tabs on guided_reports.pl will not filter based on that value. REPORT_GROUP authorized values with alphabetic and numeric values do work - it's only purely numeric values that cause the tab filtering to fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 40540] New: OPAC generates warnings in logs when no results are found
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40540 Bug ID: 40540 Summary: OPAC generates warnings in logs when no results are found Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: oleonard(a)myacpl.org When no results are found, a warning: [WARN] Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-results.tt line 76. is generated in [plack-]opac-error.log -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 40675] New: Carriage return in patron note message breaks SIP
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40675 Bug ID: 40675 Summary: Carriage return in patron note message breaks SIP Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org If an OPAC message is pasted into a Koha patron's record which includes a carriage return, it breaks the line and SIP. A user at the Kiosk may find they can no longer log in to the SIP kiosk. The SIP2 specification uses the carriage return as the message terminator. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32