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

[Bug 28833] New: Speed up holds queue builder via parallel processing
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28833 Bug ID: 28833 Summary: Speed up holds queue builder via parallel processing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The holds queue builder can take a very long time to run on systems with many holds. For example, a partner with 124,784 unfilled ( not found ) holds, is taking about 64 minutes to run. If we run that same number of holds in 5 parallel chunks ( splitting the number of records as evenly as possible, but *not* taking into account the holds per bib ), it takes 21.5 minutes. If we use 10 loops, it takes less then 14 minutes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 20053] New: Drop type attribute "text/javascript" used in OPAC template
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20053 Bug ID: 20053 Summary: Drop type attribute "text/javascript" used in OPAC template 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: indradg(a)l2c2.co.in QA Contact: testopia(a)bugs.koha-community.org If you run the Koha OPAC pages through the W3C validator it generates warnings about type attribute "text/javascript", since W3C now officially describes this as obsolete in HTML5 but still conforming to the standard with warnings [1] Since we are already pumping up HTML5 with <!DOCTYPE html>, I was thinking if we should consider an omnibus update to the following 47 templates so affected. The 47 templates: includes/calendar.inc includes/columns_settings.inc includes/datatables.inc includes/doc-head-close.inc includes/greybox.inc includes/opac-bottom.inc includes/password_check.inc includes/slip-print.inc modules/clubs/clubs-tab.tt modules/clubs/enroll.tt modules/opac-account.tt modules/opac-advsearch.tt modules/opac-auth-detail.tt modules/opac-auth-MARCdetail.tt modules/opac-auth.tt modules/opac-basket.tt modules/opac-course-details.tt modules/opac-course-reserves.tt modules/opac-detail.tt modules/opac-downloadshelf.tt modules/opac-full-serial-issues.tt modules/opac-idref.tt modules/opac-illrequests.tt modules/opac-imageviewer.tt modules/opac-MARCdetail.tt modules/opac-memberentry.tt modules/opac-messaging.tt modules/opac-overdrive-search.tt modules/opac-passwd.tt modules/opac-password-recovery.tt modules/opac-readingrecord.tt modules/opac-request-article.tt modules/opac-reserve.tt modules/opac-results-grouped.tt modules/opac-results.tt modules/opac-review.tt modules/opac-search-history.tt modules/opac-shareshelf.tt modules/opac-shelves.tt modules/opac-showreviews.tt modules/opac-suggestions.tt modules/opac-tags.tt modules/opac-topissues.tt modules/opac-user.tt modules/sco/help.tt modules/sco/printslip.tt modules/sco/sco-main.tt Reference: [1] https://www.w3.org/TR/2017/REC-html52-20171214/obsolete.html#warnings-for-o… -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 40163] New: Several http links should be moved to https
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40163 Bug ID: 40163 Summary: Several http links should be moved to https Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org FSF and GNU links should be moved to HTTPS. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 13580] New: item circ history has 'last seen' labeled wrong
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '26

05 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13580 Bug ID: 13580 Summary: item circ history has 'last seen' labeled wrong Change sponsored?: --- Product: Koha Version: master Hardware: All URL: cgi-bin/koha/circ/bookcount.pl?&biblionumber=106124&bi =106124&itm=140197 OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, sophie.meynieux(a)biblibre.com CC: katrin.fischer(a)bsz-bw.de CC: sophie.meynieux(a)biblibre.com On this page: cgi-bin/koha/circ/bookcount.pl?&biblionumber=106124&bi=106124&itm=140197 the 'last seen' column is actually the timestamp - not the date last seen so it's confusing. The label should be changed or the value should be changed. --- Comment #1 from Owen Leonard <oleonard(a)myacpl.org> --- *** Bug 13581 has been marked as a duplicate of this bug. *** --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, it's not quite the timestamp either. It looks like a calculated date on when the item was 'last seen' in this library. It uses the newest date and time from issues, old_issues and branchtransfers. Maybe 'last seen at library'? --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, it's not quite the timestamp either. It looks like a calculated date on when the item was 'last seen' in this library. It uses the newest date and time from issues, old_issues and branchtransfers. Maybe 'last seen at library'? --- Comment #4 from Sophie MEYNIEUX <sophie.meynieux(a)biblibre.com> --- The pb with this timestamp is that it is changed by anonymisation -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 39322] New: When pseudonymizing don't fetch patron attributes if none are kept
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '26

05 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39322 Bug ID: 39322 Summary: When pseudonymizing don't fetch patron attributes if none are kept Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 37001] New: Locale ignored for serial numbering when using {MonthName} {DayName} substitutions
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37001 Bug ID: 37001 Summary: Locale ignored for serial numbering when using {MonthName} {DayName} substitutions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Moved from bug 35646 comment 17. Tt doesn't work because we don't set Locale for the DateTime objects we create in Koha::DateUtils: https://metacpan.org/pod/DateTime#Locales We could easily pass through the 'locale' from the Serial (subscription table) however, I spot tested and got an error for 'Ethiopic'/'gez' though it is listed here: https://metacpan.org/pod/DateTime::Locale::Catalog Our list comes from here: https://www.loc.gov/standards/iso639-2/php/code_list.php Maybe our datetime modules need an update? Here is a full list of ones that throw an error: Invalid locale code or name: akk Invalid locale code or name: tut Invalid locale code or name: grc Invalid locale code or name: ave Invalid locale code or name: bnt Invalid locale code or name: bra Invalid locale code or name: cel Invalid locale code or name: chp Invalid locale code or name: cho Invalid locale code or name: chu Invalid locale code or name: syc Invalid locale code or name: cop Invalid locale code or name: cre Invalid locale code or name: prs Invalid locale code or name: dgr Invalid locale code or name: egy Invalid locale code or name: gez Invalid locale code or name: gem Invalid locale code or name: got Invalid locale code or name: gwi Invalid locale code or name: her Invalid locale code or name: hit Invalid locale code or name: inc Invalid locale code or name: iku Invalid locale code or name: ipk Invalid locale code or name: ira Invalid locale code or name: jrb Invalid locale code or name: csb Invalid locale code or name: lad Invalid locale code or name: lat Invalid locale code or name: myn Invalid locale code or name: dum Invalid locale code or name: enm Invalid locale code or name: frm Invalid locale code or name: gmh Invalid locale code or name: mga Invalid locale code or name: mul Invalid locale code or name: nah Invalid locale code or name: zxx Invalid locale code or name: nya Invalid locale code or name: arc Invalid locale code or name: ang Invalid locale code or name: fro Invalid locale code or name: goh Invalid locale code or name: peo Invalid locale code or name: pro Invalid locale code or name: ota Invalid locale code or name: pal Invalid locale code or name: pli Invalid locale code or name: pbr Invalid locale code or name: pra Invalid locale code or name: roa Invalid locale code or name: rom Invalid locale code or name: sam Invalid locale code or name: sem Invalid locale code or name: den Invalid locale code or name: sla Invalid locale code or name: wen Invalid locale code or name: sux Invalid locale code or name: syr Invalid locale code or name: tgl Invalid locale code or name: tet Invalid locale code or name: uga Invalid locale code or name: mis -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 39371] New: Holds to Place Count should have a character limit
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39371 Bug ID: 39371 Summary: Holds to Place Count should have a character limit Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: Laura.escamilla(a)bywatersolutions.com Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the 'Holds to Place' count does not have a character limit. Which means that if a staff member accidentally scans a barcode into this field and saves, it could lead to thousands of reserves even if there is a hold limit of 100 or less. Adding a character limit could help prevent future issues with this field. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 40202] New: Odd placement of additional fields in acquisitions advanced search form
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40202 Bug ID: 40202 Summary: Odd placement of additional fields in acquisitions advanced search form Change sponsored?: --- 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: clemens.tubach(a)kit.edu, michaela.sieber(a)kit.edu The placement of the additional fields on the advanced search in the acquisitions module appears inconsistent with other pages. To test: - Add some searchable additional fields for baskets and order lines - Go to the acquisitions module and click on "Advanced search" in the left navigation - Verify that the additional fields display between basket group and order line We think it would make more sense if the additional fields displayed at the bottom of the form, grouped by basket and order line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35617] New: Make phone number as match point in in Identity providers
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35617 Bug ID: 35617 Summary: Make phone number as match point in in Identity providers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: slavashishkin(a)gmail.com Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 31378 Currently, the system supports match points by -email, -userid, and -cardnumber. Many external authorization systems have the authentication by phone number, which is also required for libraries. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31378 [Bug 31378] Add a generic OAuth2/OIDC client implementation -- You are receiving this mail because: You are watching all bug changes.

1 14