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

[Bug 23228] New: Add option to automatically display payment receipt for printing after making a payment
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '26

24 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 Bug ID: 23228 Summary: Add option to automatically display payment receipt for printing after making a payment Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Some libraries would like an auto-popup after making a payment so librarians don't have to navigate to the accounts page, locate the new payment, then click the print button. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 40986] New: Add some reindexing examples to rebuild_elasticsearch.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '26

24 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40986 Bug ID: 40986 Summary: Add some reindexing examples to rebuild_elasticsearch.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org I want to document some examples of "advanced" usage of rebuild_elasticsearch.pl using --where SQL I think the best place is to add them to the POD of the script itself (because in my experience this has the highest success rate of keeping it up to date) We could then add to the docs / the wiki etc instructions on how to show this examples (i.e. `rebuild_elasticsearch.pl --help`) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 41703] New: Notice needed when claims return is resolved
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41703 Bug ID: 41703 Summary: Notice needed when claims return is resolved Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be really helpful and desirable to have a notice automatically generated notifying the patron that a Claims Returned has been resolved. The notice should be configurable like other notices, and contain bibliographic info, along with the resolution reason. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37694] New: Batch checkout warns but doesn't revert hold marked waiting for another patron
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37694 Bug ID: 37694 Summary: Batch checkout warns but doesn't revert hold marked waiting for another patron Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: Enable BatchCheckouts and set several patron categories as eligible to batch check out. Have holds trapped and waiting for another patron (Patron A). Batch check out waiting holds to a different patron (Patron B). You'll see a warning: "This item is waiting for another patron. This item is on hold for another patron. The hold will be overridden, but not cancelled." Leave item checkboxes selected and confirm the checkout. See that item(s) show status of checked out to Patron B and waiting on the shelf for Patron A. If the override is permitted, the waiting hold should be reverted, as happens in standard checkout. Confirmed behavior in 23.05 and 24.05. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 37140] New: Add vendor automatically to 952 $e when creating items for serials
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37140 Bug ID: 37140 Summary: Add vendor automatically to 952 $e when creating items for serials Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org On receiving a serial in the serials module, it would be helpful to add the id of the vendor automatically to the item In 952 $e (Source of acquisition), if the subscription is set to "create an item record", and the subscription has a vendor. Similar to the acquisition module, where the vendor is already added automatically to the items. To test: 1. If necessary, set 952 $e in the bibliographic framework to visible in the staff interface and the editor. 2. Go to serials 3. Create a subscription with a vendor and the setting “create an item record” and save it. 4. Go to serial collection. 5. Set a serial issue from status “Expected” to “Arrived” 6. The vendor in subfield “e” (Source of acquisition) in the item form is empty. But it would be nice if the vendor was filled in automatically. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 40397] New: Should paid for be reflected by a credit/refund/write off?
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40397 Bug ID: 40397 Summary: Should paid for be reflected by a credit/refund/write off? Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When an item is lost and the patron is charged, and then the item is returned, a refund or credit is issued and the charge removed. That item then shows as paid for in the record. Should this be the case? What is particularly confusing is if this item is lost again and charged for. The record will show paid for. Should the conditions for this paid for status in the item record be refined so that it does not mislead staff into thinking it is paid for when in fact it is not? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 39674] New: Self Check blocks decreaseLoanHighHolds items
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39674 Bug ID: 39674 Summary: Self Check blocks decreaseLoanHighHolds items Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Currently decreaseLoanHighHolds blocks checkout in SCO, with no explanation or option. This is frustrating to patrons and doubles work. It would be preferable if the SCO had admin settings to A) Allow checkout and highlight the reduced loan period. B) Allowed the patron to see a modal with the reduced loan time and choose to check the item out or not. C) Allow to block the checkout with a defined message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 32557] New: Implement SIP2 no block flag for checkin messages
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32557 Bug ID: 32557 Summary: Implement SIP2 no block flag for checkin messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The "no block" flag for SIP2 checkin messages has never been implemented. Bug 32515 fixed the issue where a non-existent subroutine was called if the no-block flag has passed. We should implement a no-block version of the checkin subroutine. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32516] New: SIP2 no block flag on renewals is passed, but not used
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32516 Bug ID: 32516 Summary: SIP2 no block flag on renewals is passed, but not used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org C4/SIP/ILS.pm 429 sub renew { 430 my ($self, $patron_id, $patron_pwd, $item_id, $title_id, 431 $no_block, $nb_due_date, $third_party, no_block does not appear elsewhere in the routine -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 37354] New: Bookings should respect circulation rules for max loan periods
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '26

23 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37354 Bug ID: 37354 Summary: Bookings should respect circulation rules for max loan periods Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, david(a)davidnind.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, katrin.fischer(a)bsz-bw.de, kkrueger(a)cuyahogalibrary.org, kyle.m.hall(a)gmail.com, laurence.rault(a)biblibre.com, nick(a)bywatersolutions.com, testopia(a)bugs.koha-community.org, thibaud.guillot(a)biblibre.com Depends on: 34440 +++ This bug was initially created as a clone of Bug #36271 +++ The original bug for this took on a life of its own and became broader in scope adding a series of circulation rules for the bookings system I've cloned it here to propose my original more limited-in-scope solution using existing circulation rules for loan length * renewals count. --------------------------------------------------------------- Currently, bookings are on/off at the item level, but the booking period is entirely open meaning an item can be booked for any period. We should refine this to allow libraries to control the maximum length an item can be booked for. During the original development, I suggested perhaps we should set the maximum to the loan length of the item times the max renewals from the circulation rules.. However, I didn't get much feedback as to whether this was appropriate or whether people wanted a distinct rule for these items or another alternative. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34440 [Bug 34440] Add warm-up and cool-down periods to bookings -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62