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

[Bug 41775] New: Allow Koha's message transport types to be pluggable
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '26

05 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41775 Bug ID: 41775 Summary: Allow Koha's message transport types to be pluggable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be really great if Koha plugins could define new message transport types that only that plugin would operate on. This would make it easy to support more esoteric messaging platforms ( signal, whatsapp, pushover, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41774] New: Add ability to read encryption key from environment variable
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '26

05 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41774 Bug ID: 41774 Summary: Add ability to read encryption key from environment variable Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From a security standpoint it would be useful to be able to store Koha's encryption key in an environment variable. This is particularly useful in containerized environments, but is not limited to that use case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Danielle M. <dmeininger591(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmeininger591(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #238 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Victor Grousset/tuxayo from comment #236) > qa script is finding various issues. Like tidy, spelling, filters, > permissions. All minor stuff. > > Tidy stuff might be a pain, we shouldn't use tidy commits anymore, it should > be done inline. If the untidy stuff comes from many commits (maybe old > commits were done on a machine without the git hook that should tidy > automatically), then it would be bad to have all the fixes in the last > commit. > If that's the situation, it might work to do an interactive rebase and mark > all commits for "edit". Then amend them one by one without any change, but > it should trigger the tidy hook. Hopefully that doesn't start doing tons of > conflicts if commits touch the same places that were untidy. In that case, I > think it would be a ok have tidy commit. The history on main shows there are > a very few other tidy commits. So we can sneak another one if that's needed > to fix an old mess without being a total pain. > > Hope that helps. > > > ---- > > > Code coverage is good, whether on new code and changes being covered. And on > test removal not removing coverage on any still existing code. Currently working my way through said issues, and I've got a quick question on one of them if that's alright: [FAIL] koha-tmpl/intranet-tmpl/prog/js/vue/stores/circulation-rules.js FAIL forbidden_patterns forbidden pattern: Use __("") instead of _("") (line 35) seems to have been triggered by this regex: /overdue_(\d+)_has_rules/. Would that be a case of the qa script picking up on something it shouldn't? -- You are receiving this mail because: You are watching all bug changes.

1 0

[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