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

[Bug 19917] New: Holds for self registered patrons
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '25

17 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19917 Bug ID: 19917 Summary: Holds for self registered patrons 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There needs to be a switch in place that does not allow a hold to be triggered if the hold is for a patron in the self registered category. Our library workflow: * Allows self registered patrons to place a couple of holds. * Doesn't assign an automatic card number. * Prints specialized hold slips * Allows self pickup Ideally, we would want the preference to not trigger the hold if the self registration category is in use on the patron with the hold, and a message to come up asking staff to go ahead and assign a card number, or something to that effect. Right now, when the hold is triggered, the slip comes out wrong because there is data missing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20575] New: Auto-renewals to use current patron category when renewing as opposed to when item was issued.
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '25

17 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20575 Bug ID: 20575 Summary: Auto-renewals to use current patron category when renewing as opposed to when item was issued. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Increasing the functionality of the Auto=-renewal process to have Koha look at the circulation and fine rule table at time of renewal instead of keeping the same circ and fine rules when the item was issued. If a patron category has been changed during when an item has been checked out the patron, this is not reflected in the auto-renewal process. For example, if a student is allowed to auto renewal items but they are changed to a different patron category who can not auto-renewal-Koha will still allow the auto-renewal given the rules were set when the item was checked out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 30030] New: Test t/db_dependent/Koha/Patrons.t is_going_to_expire fails randomly
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '25

14 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30030 Bug ID: 30030 Summary: Test t/db_dependent/Koha/Patrons.t is_going_to_expire fails randomly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org See https://jenkins.koha-community.org/view/master/job/Koha_Master_U18/lastComp… not ok 9 - On invalid "is going to expire" date, the method should not crash with "Invalid local time for date in time zone" -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 31113] New: Permission change to so user can use marc modification template only when adding or editing single record
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31113 Bug ID: 31113 Summary: Permission change to so user can use marc modification template only when adding or editing single record 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: aspencatteam(a)clicweb.org QA Contact: testopia(a)bugs.koha-community.org Would like to see a permission to allow the application of marc modification template to single record, without having the permission to do batch record modification. This would allow admin to create marc modification template that a novice cataloger could use to supply certain fields they probably would not know to change. (Like in leader, 008, 007). We would not want them to be able to do batch record modification - just use template on single record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 31323] New: Edit item highlighting problem
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31323 Bug ID: 31323 Summary: Edit item highlighting problem 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To reproduce: 1 search the catalog 2 find a record with 1 item 3 click the edit button in the item table (to the right of Spine Label) 4 when I click "save changes" the item is still highlighted yellow It appears like the '.active' class is lingering. I think this might be caused by Bug 27526? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 30343] New: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30343 Bug ID: 30343 Summary: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Previously we had only used the e-mail delivery method in overduerules.pl. This worked great. When a patron didn't have an e-mail address, a printed notice was added to the attachment.txt file for printed notices. Now we have phone and sms added as delivery methods. However, if ANY of these fail (no SMS number or no primary phone, or in the case of Twilio, if the same notice is sent via e-mail or sms, the phone status shows as deleted to prevent duplication) a printed notice is added to the attachment.txt file for printed notices. There should be option to determine if a printed notice is generated if ANY of the other methods fail, or if ALL of the methods fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 20338] New: Preference noissuescharge should not be considered 5 when it is actually 0
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '25

08 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20338 Bug ID: 20338 Summary: Preference noissuescharge should not be considered 5 when it is actually 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the noissuescharge is set to 0, then limit 5 is used, see FIXME comment in circ/circulation.pl after bug 19933 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25219] New: Include note in fines-related system preferences which can be disabled by leaving them blank
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '25

08 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25219 Bug ID: 25219 Summary: Include note in fines-related system preferences which can be disabled by leaving them blank 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The syspref OPACFineNoRenewals includes the note "(leave blank to disable)." The sysprefs maxoutstanding, noissuescharge, NoIssuesChargeGuarantees, and MaxFine can all be disabled by leaving them blank, as well. It'd be helpful to include that same "(leave blank to disable)" message to make it clear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 31281] New: Overdue notices reply-to email address of a branch not respected
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31281 Bug ID: 31281 Summary: Overdue notices reply-to email address of a branch not respected Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: nason.bimbe(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The overdue notification email is sent from the correct email address as set up for the branch, however the reply-to email address though set for the branch is not the one used. The email has reply-to address of a different branch and not even the default one as set up in system preferences. Below is set up (however I have renamed the branches and email addresses for the purpose of this bug report). So what happened is the overdue notification was sent using LibraryB email address however the reply-to email address on the notification is the reply-to email address of LibraryA instead of LibraryB one. This is on Koha 21.11.05.000 LibraryA settings Email: librarya(a)mlibary.whatever Reply-To: librarya(a)mlibrary.whatever Return-Path: librarya(a)mlibrary.whatever LibraryA settings Email: libraryb(a)mlibary.whatever Reply-To: libraryb(a)mlibrary.whatever Return-Path: libraryb(a)mlibrary.whatever LibraryC settings Email: libraryc(a)mlibary.whatever Reply-To: libraryc(a)mlibrary.whatever Return-Path: libraryc(a)mlibrary.whatever SysPref setting: KohaAdminEmailAddress: library(a)library.whatever ReplytoDefault: library(a)library.whatever -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 33473] New: Allow to send email receipts for payments/writeoff manually instead of automatically
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33473 Bug ID: 33473 Summary: Allow to send email receipts for payments/writeoff manually instead of automatically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 31448 With bug 31448 it's possible to re-send a failed or lost email receipt. It would be nice if you could turn off the automatic sending of receipts by email and send them just manually whenever requested. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31448 [Bug 31448] Add option to re-send email receipt when UseEmailReceipts is enabled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29