June 2024 - Koha-bugs - lists.koha-community.org

[Bug 32878] New: Make it impossible to renew the item if it has active item level hold
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '25

15 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32878 Bug ID: 32878 Summary: Make it impossible to renew the item if it has active item level hold Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Circulation Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 33120] New: Batch Patron Modification - Circulation Note Overwrites
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '25

15 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33120 Bug ID: 33120 Summary: Batch Patron Modification - Circulation Note Overwrites Change sponsored?: --- 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: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org When using Batch Patron Modification to add a new "Circulation Note" field, the new entry wipes out any existing Circulation Notes on the patrons accounts. This is problematic, especially for accounts that require we keep historical records of patron interactions with staff. I propose that the newly added note be added to the end of whatever Circulation Notes already exist on the account, i.e.: Note 1; Note 2; Note 3; New Note Added Today Alternatively, I'd love to see the Circulation Note field act similar to the Patron Message field, where the librarian/date/time are logged when notes are added to the accounts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[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 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 35812] New: Should specify canonical URLs to help search indexers
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35812 Bug ID: 35812 Summary: Should specify canonical URLs to help search indexers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org So we've recently added our Koha site to Google Search Console and became bombarded by its complains about lack of defined canonical URLs for pages. This is mostly a problem for bib details page. For main page, you can have three possible URLs that will all load main page: - / - /index.html - /cgi-bin/koha/opac-main.pl I think "/" should be specified as canonical URL, which could even "lazily" be achieved by following Apache directives (these will append the Link header to all three URLs above and nothing else) (they could be added to debian/templates/apache-shared-opac.conf): Header always append "Link" "</>; rel=canonical" "expr=%{REQUEST_URI} == '/index.html'" Header always append "Link" "</>; rel=canonical" "expr=%{REQUEST_URI} == '/cgi-bin/koha/opac-main.pl'" The situation gets a bit more complicated with bibs, because trying to solve it with Apache directives becomes complex if even possible, instead of another solution (note that we can also have a HTML tag instead of HTTP header). Koha links to pages with URLs in the format `/cgi-bin/koha/opac-detail.pl?biblionumber=1234`, but the Apache config has defined nice links in the format of `/bib/1234`. With `opac-detail.pl` page you get some junky parameters appeared after you reach the page from Koha search such as: - /cgi-bin/koha/opac-detail.pl?biblionumber=1234 - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=se,phr:"Something" - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=an:3200 - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&query_desc=an:1846 and su-to:Something and itype:BK and su-to:Environment and su-to:Environment - /cgi-bin/koha/opac-detail.pl?biblionumber=1234&fbclid=FSD8ufs98jf39jfes80jfds8jfsd - /cgi-bin/koha/opac-detail.pl?bib=1234 To top it off, if you do a search and there's only one search result, you get redirected directly to opac-detail, confusing Google even further (I actually think it's worthy of a separate bug to add some kind of notice that you were redirected cause there was only one result, but that's a matter for another discussion...). So the solution there would also be to specify the canonical link as "/bib/1234" with no params, but I think it might be best off done in code rather than Apache config there. The end result of these would be that search results would have nice links, without weird params such as query_desc added to the indexed pages, which is awful (as the user coming from search has nothing to do with that query as when it was indexed). This would solve also another potential problem, in that such silent redirect from search results could make a search engine think that the search URL is the canonical URL (as when it's not specified, it's up to the search engine to detect duplicate and decide, but it can do so wrongly and against its own rules sometimes, as we've observed). And finally, the search URLs could also be made canonical from "/cgi-bin/koha/opac-search.pl" to "/search", however this time with keeping all URL query parameters. All of this is somewhat related to Bug 18410, but not blocked by it by any means, as the URL aliases I've described above are actually in the Apache config already for a long time, and don't depend on overall Koha routing overhaul. Btw: it's better to use full OPAC base URL instead of just "/" if we can, this will help with deduplicating indexed URLs in case your Koha is available under multiple aliased domains or is under process of changing domains (or is technically available under both http and https without a redirect, and search treats those as separate sites!). But doing so requires pure code solution instead of Apache directives. -- You are receiving this mail because: You are watching all bug changes.

1 38