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

[Bug 28870] New: Cart shipping fails because of Non-ASCII characters in display-name of reply-to address
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '25

15 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28870 Bug ID: 28870 Summary: Cart shipping fails because of Non-ASCII characters in display-name of reply-to address Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ulrich.kleiber(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org After the upgrade from 18.11 to 20.11, users with non-ASCII characters (e.g. German umlauts) in their first name or surname can no longer send shopping carts because the newly introduced email address validation of the create function of Email.pm fails. A possible solution would be to omit the display name generated from first name and surname in opac-sendbasket.pl. diff --git a/opac/opac-sendbasket.pl b/opac/opac-sendbasket.pl index 55dc7546bc..c4dee93e3d 100755 --- a/opac/opac-sendbasket.pl +++ b/opac/opac-sendbasket.pl @@ -59,7 +59,7 @@ if ( $email_add ) { my $user_email = $patron->first_valid_email_address || C4::Context->preference('KohaAdminEmailAddress'); - my $email_replyto = $patron->firstname . " " . $patron->surname . " <$user_email>"; + my $email_replyto = $user_email; my $comment = $query->param('comment'); # Since we are already logged in, no need to check credentials again -- You are receiving this mail because: You are watching all bug changes.

1 86

[Bug 40300] New: multiple semi-colons in series part name ($p)
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40300 Bug ID: 40300 Summary: multiple semi-colons in series part name ($p) Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bernard.scaife(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org In both intranet and OPAC full detail display an 830 series field which has a part $p displays multiple semi-colons if the field contains one. There is a part template which needs to use chopPunctuation. 1. Add series field 830 with $a Analecta Gregoriana, Series Facultatis Philosophiae. $p Sectio B ; $v n. 14. 2. Observe OPAC or intranet detail record: Analecta Gregoriana, Series Facultatis Philosophiae. Sectio B ; ; n. 14. 3. Should be Analecta Gregoriana, Series Facultatis Philosophiae. Sectio B ; n. 14. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 36689] New: SelfCheckAllowByIPRanges does not work
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36689 Bug ID: 36689 Summary: SelfCheckAllowByIPRanges does not work Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org If I put our IP address in this setting, it does not work. The self check just defaults to the catalog. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 16552] New: Add the ability to change the default holdings sort
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16552 Bug ID: 16552 Summary: Add the ability to change the default holdings sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org This new enhancement will add the ability to change the default holdings sort on OPAC displays to be by library. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 16759] New: make opac holdings table configurable
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16759 Bug ID: 16759 Summary: make opac holdings table configurable Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jweaver(a)bywatersolutions.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: nicole(a)bywatersolutions.com Work to be done: * Make the holdings table in the OPAC configurable using the columns editor * Add columns hidden by default for home branch, holding branch, copy number and shelving location -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 35319] New: Default sorting of the holdings table with OPACHoldingsDefaultSortField is broken
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35319 Bug ID: 35319 Summary: Default sorting of the holdings table with OPACHoldingsDefaultSortField is broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org No matter which setting is chosen, the sorting remains on the itemtype column. If the item type column is hidden via table settings, it still seems to apply. None of the other columns shows as sorted judging from the small arrow icons on top. Confirmed in 23.05 and 22.11. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 27572] New: Should OpacLocationBranchToDisplay be replaced by table settings?
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27572 Bug ID: 27572 Summary: Should OpacLocationBranchToDisplay be replaced by table settings? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 The OpacLocationBranchToDisplay system preference essentially serves the purpose of hiding or showing columns in the items table in the record details page on the OPAC, namely the home library column and the current library column. Since we now have Administration > Table settings that we can use to show or hide columns, is this system preference still useful? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 35659] New: OAI Harvester
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35659 Bug ID: 35659 Summary: OAI Harvester Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Koha needs to be able to harvest records from OAI-PMH repositories. This patch implements a cronjob-based OAI harvester, deliberately kept simple and consistent in its configuration with what we already have in Koha for other data sources, such as Z3950 and SRU. It is sponsored by KohaLa, its goals and implementation have been previously discussed on the koha and koha-devel mailing-lists, as well as in a presentation at KohaCon'23 in Helsinki: "Let's add an OAI-PMH harvester in Koha" by Sonia Bouis. Some of the code and ideas are based on a previous implementation of an OAI harvester by David Cook (See BZ 25905 and 10662). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 214

[Bug 40606] New: Remove parentheses and italics from shelving location in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '25

14 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40606 Bug ID: 40606 Summary: Remove parentheses and italics from shelving location in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Now that bug 15461 is in Koha, I noticed that even though the shelving location was moved to its own column, the formatting and parentheses were left. That looks weird now that it's in its own colum. To recreate : 1. Go to a detailed record (make sure it has an item and the item has a shelving location, I used http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=161 --> Note that the shelving location is in parentheses and in italics I noticed that some records show the location without the parentheses already, I'm not sure why some have parentheses and some don't. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 38042] New: Wrong values in Item type form on acqui/neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38042 Bug ID: 38042 Summary: Wrong values in Item type form on acqui/neworderempty.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Not sure of the right component for this problem, but it has an impact on our acquisition workflow. The problem seems to have been introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 When entering a manual order, the form on acqui/neworderempty.pl imposes a "Item type" field with a drop-down menu containing wrong values. Our configuration (defined with our vendor 2 years ago, and everything was fine in 21.11) : - UNIMARC - item-level_itypes : specific item - record level item type defined in 099$t : mapped with biblioitems.itemtype ; using TYPEDOC authorized values - item item type defined in 995$r : mapped with items.itype ; using value:itemtypes authorized values When you create a record in acqui/neworderempty.pl, the "Item type" fills the 099$t, so the form must display the TYPEDOC values. It was the (logical) behavior before the change introduced by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 Now, the form display the "itemtypes" values. That's not good, it creates a data coherence issue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17