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

[Bug 35635] New: Expand Patron attribute type mandatory field
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '25

02 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35635 Bug ID: 35635 Summary: Expand Patron attribute type mandatory field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Within Patron attribute types there is a checkbox to make the attribute mandatory. Some libraries need to be able to make patron attribute types mandatory on the OPAC but not the staff interface, or vise versa. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 29145] New: Allow patrons to have overdue items that would not result in debarment when removing overdue debarments
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '25

02 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29145 Bug ID: 29145 Summary: Allow patrons to have overdue items that would not result in debarment when removing overdue debarments Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The default behavior when returning an item, is to check if a patron is debarred, in that case check if the patron has any other overdue items left, and if not to lift the debarment. One might argue that it would be more logical to lift the debarment on the same conditions on which the Patron was debarred, so if the patron is in a state that would not cause debarment, the patron should not be debarred. That is: only if the patron has items that are overdue enough to cause restriction/debarment the debarment should be maintained. This patch provides a system preference, that if set instead of checking for any delayed items on returning an item, uses the delay used for restrictions to check for items exceeding that limit, and if none are found lifts the debarment. (Stefan Berndtsson at Gothenburg University library is the original author of this patch). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[Bug 41344] New: Payment confirmation needs modal
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41344 Bug ID: 41344 Summary: Payment confirmation needs modal Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk I am constantly getting confused about whether the payment took or not because I am expecting a modal on the screen to confirm payment. Instead it blends in with the refreshed page in a blue alert field. It would be preferred if the confirmation with the print or email buttons appeared in a modal instead of an alert, or if we had the option of either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 26058] New: Add ability for AllowHoldsOnPatronsPossessions to be limited by item type, collection code or shelving location
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26058 Bug ID: 26058 Summary: Add ability for AllowHoldsOnPatronsPossessions to be limited by item type, collection code or shelving location Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be useful to be able to limit the AllowHoldsOnPatronsPossessions system preference by item type, collection or shelving location. For instance, we have multiple volumes of graphic novels attached to the same bib record so we have AllowHoldsOnPatronsPossessions set to Allow. We have hotspots and laptops and would like to prevent patrons from being able to place holds on them when they already have one checked out. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 29098] New: Double confirm running resource intensive Overdues report
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29098 Bug ID: 29098 Summary: Double confirm running resource intensive Overdues report Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Very large libraries still have the option to run the resource intensive overdues.pl with no filters, even when the syspref is on to require filters before running it. I propose a confirmation message to ensure users know that the thing they are requesting is very resource intensive and may not complete, as we don't want to take away the functionality but I do think people should really be sure they know what they are doing when they click through with no filters on this page. Other solutions to this problem welcome - my requirements are - the option to run the full report should still be available, as it is now - users should be duly warned and forced to confirm that they really want to do this when the no-filter case is requested. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Eric Phetteplace <ephetteplace(a)cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ephetteplace(a)cca.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9762] Log circulation overrides
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 Tomás Cohen Arazi (tcohen) <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41339 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41339 [Bug 41339] Typo 'Too many checkout' -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41197] New: opac/opac-account-pay-return.pl should not require CSRF
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41197 Bug ID: 41197 Summary: opac/opac-account-pay-return.pl should not require CSRF Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This page is intended for redirect/return from external payment vendors - they are not going to have/get a CSRF token from Koha for this. The payments are handled in a POST to the API, so this should not be a sensitive page, it just provides user confirmation. Some vendors use only a POST, we should not require CSRF on this page. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 41333] New: MOve
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41333 Bug ID: 41333 Summary: MOve Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40910] New: Log pollution for undefined/empty barcodes
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '25

01 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40910 Bug ID: 40910 Summary: Log pollution for undefined/empty barcodes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Noticed in production, when `C4::SIP::ILS::Item->new` is passed an `$item_id` that is not defined or empty -or barcodedecode makes it like that- (e.g. faulty plugins) logs get flooded with DBIx::Class errors when it should never reach the ORM with a query because there's nothing to search for. If `barcodedecode` empties the barcode, a debug log should be printed because it might be a sign of a misconfiguration or faulty plugin. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16