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

[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 41773] New: Allow Koha users without edit_borrowers to enable 2FA for their own account
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41773 Bug ID: 41773 Summary: Allow Koha users without edit_borrowers to enable 2FA for their own account Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have some cataloguing volunteers using Koha that we need to enable 2FA for and we do not want to force 2FA for all users. The cataloguing volunteers do not have access to patron records to view or edit to ensure data protection, however as they don't have edit_borrowers they can't amend their own account in order to set up their 2FA. Our current workaround is not ideal as we have to add edit_borrowers for volunteers but then add in some jquery to IntranetUserJS to hide the patron and circulation tiles/buttons. It would be great to see a workflow that allowed a user with only 'catalogue' permission enabled and the ability to manage two factor authentication for themselves when set as enabled or enforced. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41772] New: Record tendered and change amounts for transactions
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41772 Bug ID: 41772 Summary: Record tendered and change amounts for transactions Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Currently, we pass tendered and change amounts around during a transaction but only for that initial receipt print. Sometimes, you need to reprint a receipt after the fact, or may want to look at the historical detail of transactions at cashup time. I propose storing this detail somewhere in Koha for future reference in both the cases above. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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 41770] New: Ability to create a saved search filter only visible for its creator
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41770 Bug ID: 41770 Summary: Ability to create a saved search filter only visible for its creator Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice for a librarian to create a saved search filter only visible for themselves (based on their login) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 14962] Temp Shelving Location
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Rhonda Kuiper <rkuiper(a)roundrocktexas.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkuiper(a)roundrocktexas.gov -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10993] Transfer limits should be checked when placing a hold/reservation in OPAC.
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10993 Arthur Suzuki <arthur.suzuki(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41768 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 --- Comment #206 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- Created attachment 192459 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=192459&action=e… Bug 7376: (QA follow-up) Trivial typo fixes Signed-off-by: Martin Renvoize <martin.renvoize(a)openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0