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

[Bug 43119] New: Checkout and hold action logs are not displayed correctly
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43119 Bug ID: 43119 Summary: Checkout and hold action logs are not displayed correctly Initiative type: --- Sponsorship --- status: 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: matt.blenkinsop(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- Since bug 29016 we have lost the item information in action logs for checkouts and holds. Previously a link to the item along with any override information would be displayed whereas now we just get raw JSON data. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 41267] New: It should be possible to prevent some itemtypes from filling other biblio level holds
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 Bug ID: 41267 Summary: It should be possible to prevent some itemtypes from filling other biblio level holds Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com See bug 40792 and related/dependent bugs. Currently Koha will fill any title level holds on a record when another item on the record is checked out. Some libraries want this behaviour, others don't want it for all item types. E.g. - A library has 'lucky day' item which cannot have holds placed. If a patron finds them in the library they can check them out. In some libraries they have similar circ rules and so the item should fill the hold In other libraries the lucky day items have a shorter circulation period, so the patron may still want the regular book with a longer circ We should add a circulation rule to determine if an item type should or should not fill other biblio level holds Filing as a bug since many libraries consider this a regression -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 43072] New: Hold policies display incorrectly in circ rules page
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43072 Bug ID: 43072 Summary: Hold policies display incorrectly in circ rules page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 41267 Target Milestone: --- Bug 41267 added a new hold policy type to the "Default holds and bookings policies by item type" section at the bottom of the page, "Fill other record level holds on record at checkout." If this policy is set to Yes or undefined, an item of the given itemtype can fill a bib-level hold even if the itemtype doesn't otherwise allow holds. If the policy is set to No, then the itemtype will not fill record-level holds. On upgrade, Bug 41267 does not set anything in the circulation_rules for this policy. After upgrade, any itemtype that has a value set for something else in this section will show a value of "No" for "Fill other record level holds on record at checkout" even though this policy isn't actually set. So the upgrade doesn't actually change any circ behavior, but it shows an erroneous change in the circ rules. To recreate: - be on a version of Koha without this code (25.11.04 or older) - set Hold Policy = "No holds allowed" for an itemtype - upgrade Koha to a version with this code - reload the circ rules page, confirm the Default holds and bookings policies by item type section still shows your Hold Policy value and *also* shows "Fill other record level holds on record at checkout" set to "No" for your itemtype - query "select * from circulation_rules where rule_name='fill_other_biblio_holds_policy'" and confirm no rule exists in the database - confirm a record-level hold can still be filled with an item of your itemtype - update your circ rules to actually save a No for "fill other record level holds" - confirm this now shows in your circ rules query - confirm a hold no longer fills It seems simplest to make this table show "Yes" when no policy exists. But on the other hand in current main I cannot set any rule in this table without also setting a "Fill other record level holds" value, so maybe it would be more consisten to actually save a "Yes" rule for 'fill_other_biblio_holds_policy' on any itemtype that already has something set for any other rule here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 [Bug 41267] It should be possible to prevent some itemtypes from filling other biblio level holds -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 43223] New: Diacritics break the title field population when adding to a basket from a purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43223 Bug ID: 43223 Summary: Diacritics break the title field population when adding to a basket from a purchase suggestion Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We noticed today that certain punctuation is breaking the automatic population of the title field in the bib record when adding to a basket from a purchase suggestion. To recreate: 1. Make a purchase suggestion with the character ‘ in the title field, for example: The history of rock ‘n roll. 2. Accept the purchase suggestion. 3. Create a basket for a vendor in acquisitions. 4. Click add to basket > from a purchase suggestion. 5. Select the title from step 1. Fill in the quantity and fund. 6. Click from the linked title into the basket to go to the bib record that was created. The 245 field will be empty. Not sure if this is related to 40810, but logging it as a separate issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28863] New: Cancel a Pending Notice
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28863 Bug ID: 28863 Summary: Cancel a Pending Notice Change sponsored?: --- 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: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org We would like the ability to cancel any notice that is currently "Pending" on the Notices tab in a user's account. Also, a record of which librarian cancelled the notice and date/time stamp would be very useful. Use Case: Item is discharged, hold is trapped, & notice is generated. Staff then realizes that the item is badly damaged and reverts the hold to obtain another copy. However, the notice for the original item is now Pending in the account and the email will be sent - even though the item is not on the Hold Shelf. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 40951] New: Optionally show reserve_id to users in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40951 Bug ID: 40951 Summary: Optionally show reserve_id to users in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com, trevor.diamond(a)mainlib.org The action logs for holds use the reserve_id for "object," which makes the reserve_id necessary for most searching one might want to do in that log. Unfortunately, there's no way to see that reserve_id in the staff interface without a report. For users who spend a lot of time looking at hold logs, it'd be helpful to be able to see the reserve_id from a patron's hold history and a biblio's list of current holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 41841] New: Update some patron admin templates to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41841 Bug ID: 41841 Summary: Update some patron admin templates to use grid layout for forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 41827 - Patron categories - Patron attribute types - Patron restriction types Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41827 [Bug 41827] Update authority types pages to use grid layout for forms -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 41678] New: Add a warning when max servers are reached
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41678 Bug ID: 41678 Summary: Add a warning when max servers are reached Initiative type: --- Sponsorship --- status: 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: ryan.henderson(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Hi All, We've been investigating an issue with a SIP configuration with a library who have multiple SIP units. It took us a while to find out that the issue was due to the max servers being reached. What would be a nice enhancement is adding a warning / error message into the sip logs to say that the max servers were reached. SIP2 is using prefork which from reading it seems to be able to provide this message which we currently don't seem to be doing. Kind regards, Ryan. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 18064] New: Long overdue cronjob does not follow the library' s calendar and skip closed days
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18064 Bug ID: 18064 Summary: Long overdue cronjob does not follow the library's calendar and skip closed days Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The cronjob that sets the Long overdue does not follow the library's calendar and skip closed days. However, the cronjob that sends the email (overdue notices) does follow the library's calendar. So as an example on a weekend where Monday is a holiday, the long over due may get set and chanrge the patrons account, but the email may be sent a day or 2 later. It would be good to allow the long overdue cron to follow the library calendar and skip closed days. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 84

[Bug 39631] New: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39631 Bug ID: 39631 Summary: longoverdue.pl does not consider OverdueNoticeCalendar when calculating overdue days 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the system preference OverdueNoticeCalendar is activated, the script longoverdue.pl continues to calculate overdue duration using calendar days instead of working days. This creates a discrepancy with overdue_notices.pl, which correctly uses working days for triggering overdue notices when OverdueNoticeCalendar is enabled. As a result, items may be marked as lost by longoverdue.pl before the final configured overdue notice (e.g., ODUE3) has a chance to be sent. To test 1. Set the system preference OverdueNoticeCalendar to « ignore calendar » 2. Set the following preferences: DefaultLongOverdueLostValue = Long Overdue DefaultLongOverdueDays = 15 3. Define days when the library is closed 3.1. Go to Tools > Calendar 3.2. Click on a Saturday (e.g., 2025-04-12) Fill Description = Saturdays, Click on "Holiday repeated every same day of the week." and Click on Copy to all libraries and submit 3.3. Repeat step 3.2. by clicking on Sundays (e.g., 2025-04-13) similarly. 4. Checkout an item to a patron of category type Board, and set due date to 2025-03-29 (15 days before today). 4.1. Click on "Show checkouts", click the barcode, and note the itemnumber. 5. Run: ./misc/cronjobs/longoverdue.pl --> The item should be flagged as overdue (e.g., item 378 appears in the output). 6. Now Enable the system preference OverdueNoticeCalendar. 7. Run longoverdue.pl again: --> The item is still detected as overdue, even though it should not be (due to holidays). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11