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

[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 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 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

[Bug 43232] New: Koha::Hold->age does not respect future holds
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43232 Bug ID: 43232 Summary: Koha::Hold->age does not respect future 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- Came across this when testing misc/cronjobs/holds/cancel_unfilled_holds.pl, which relies on the ->age sub. This line $age = $today->delta_days( dt_from_string( $self->reservedate ) ); just counts the number of days between today and reservedate. This is always a positive number. Future holds (having a reservedate in the future) are handled just like older holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40658] New: When sorting by local-number we should use the sort field
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40658 Bug ID: 40658 Summary: When sorting by local-number we should use the sort field Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When adding 'local-number' as a fallback sort I explicitly added sorting on 'local-number' - it should be 'local-number__sort' This avoids problems when mappings may be older and local-number itself is indexed as a string and not a number -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 42766] New: Add ScriptLog syspref and auto-logging for non-cron Koha scripts
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42766 Bug ID: 42766 Summary: Add ScriptLog syspref and auto-logging for non-cron Koha scripts Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Depends on: 42714 Bug 42714 added automatic CRONJOBS action-log entries (start and end) for scripts that declare themselves as cron jobs via 'use Koha::Script -cron'. That bug deliberately excluded non-cron scripts (admin tools, migration utilities, maintenance scripts) to avoid polluting the CRONJOBS log. This bug extends the same auto-logging idea to all Koha scripts that use bare 'use Koha::Script' (without -cron), gated behind a new ScriptLog system preference that mirrors CronjobLog. Work required: 1. Add a new 'ScriptLog' system preference (type: YesNo, default: 0). 2. Extend the INIT/END blocks in Koha::Script to call a new logscriptaction() function (or reuse/extend cronlogaction()) when ScriptLog is enabled and $_cron is false. The logged module should be distinct from CRONJOBS (e.g. 'SCRIPTS') so admins can filter the two separately in the action log viewer. 3. Implement @ARGV scrubbing before logging. Some scripts accept sensitive values on the command line (passwords, tokens). A concrete example is misc/devel/create_superlibrarian.pl which accepts --password. The mechanism should redact any argument that follows a flag whose name contains 'password', 'passwd', 'secret', 'token', or similar, replacing the value with '[REDACTED]'. Affected scripts (or a central list in Koha::Script) should be able to declare which flags are sensitive. 4. Update the system preferences admin UI (.pref file) to expose ScriptLog alongside or near CronjobLog. 5. Add tests: - Unit test for the @ARGV scrubbing logic. - Verify ScriptLog=0 suppresses logging for non-cron scripts. - Verify ScriptLog=1 creates action log entries for non-cron scripts. Test plan: 1. Apply patch. 2. Enable ScriptLog in Administration > System preferences > Logging. 3. Run a non-cron script, e.g.: perl misc/devel/create_superlibrarian.pl --userid admin --password secret 4. Check Administration > Action logs (module: SCRIPTS) and confirm a Run entry exists with the password value replaced by [REDACTED]. 5. Confirm no entry appears in the CRONJOBS module for this run. 6. Run a cron script, e.g.: perl misc/cronjobs/cleanup_database.pl --confirm 7. Confirm the entry appears under CRONJOBS (not SCRIPTS). 8. Disable ScriptLog and re-run step 3; confirm no log entry is created. 9. Run the test suite: prove t/Koha/Script.t t/Koha/Script_cron.t Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42714 [Bug 42714] Koha::Script should automatically log start and end of scripts when they are run -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 42360] [CVE-2026-70369] SQL Injection in reports/acquisitions_stats.pl via Filter parameter
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42360 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SQL Injection in |[CVE-2026-70369] SQL |reports/acquisitions_stats. |Injection in |pl via Filter parameter |reports/acquisitions_stats. | |pl via Filter parameter -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42363] [CVE-2026-70370] SQL Injection in reports/catalogue_stats.pl via the Line request parameter
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '26

05 Aug '26

1 0