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

[Bug 27859] New: Marc export for search result
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27859 Bug ID: 27859 Summary: Marc export for search result Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com This patch provides the option of exporting a search result as MARCXML or iso 2709. Ideally the export should be asynchronous but it was much trickier than first thought to fork and detach from Apache so gave that up for now. A link to the export is sent to the current user as an email as a simple way of delivering the response asynchronously (keeping it this way so don't have to refactor when/if the export is made asynchronous). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 106

[Bug 43843] New: OPAC JavaScript translations break when the Content-Security-Policy is enabled
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43843 Bug ID: 43843 Summary: OPAC JavaScript translations break when the Content-Security-Policy is enabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: f.demians(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org Depends on: 38365 Target Milestone: --- When the Content-Security-Policy is enabled on the OPAC (csp_mode "enabled" in koha-conf.xml) and the OPAC is displayed in any language other than English, all JavaScript translation functions fail: __(), __x(), __n(), __nx(), __p()... As a consequence, every script that translates a string breaks: DataTables tables (kohaTable) are not initialized, messages and dialogs are not displayed, etc. The browser console shows, on every page: Uncaught EvalError: Evaluating a string as JavaScript violates the following Content Security Policy directive because 'unsafe-eval' is not an allowed source of script: script-src 'self' 'nonce-...' Uncaught TypeError: Cannot read properties of undefined (reading 'gt') at i18n.js Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 [Bug 38365] Add Content-Security-Policy HTTP header to HTML responses -- You are receiving this mail because: You are watching all bug changes.

1 20

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

22 Oct '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 87

[Bug 39267] New: Specified due date remains for checkouts even when removing unchecking remember for session
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39267 Bug ID: 39267 Summary: Specified due date remains for checkouts even when removing unchecking remember for session 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When checking out an item for a borrower, choosing a specific due date and checking the "remember for session". If another checkout is done, removing the date and unchecking "remember for session", after the checkout has been performed, the previously set due date is still there. It's difficult to see how the correct behaviour shouldn't be that the date is cleared from the session as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 43536] New: Additional fields added to erm_agreement_periods appear in agreement as well as period
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43536 Bug ID: 43536 Summary: Additional fields added to erm_agreement_periods appear in agreement as well as period Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Target Milestone: --- When adding an additional field to erm_agreement_period, it adds it to the agreement period section, but also in the agreement section itself. I'm not sure if this is on purpose or not, but it seems a bit confusing. To recreate : 1. Add an additional field for Agreement periods 1.1. Go to Administration > Additional fields 1.2. Click "Agreement periods (erm_agreement_periods)" 1.3. Click "New field" 1.4. Enter the name "Agreement period additional field" 1.5. Click "Save" 2. Add an additional field for Agreements 2.1. Go to Administration > Additional fields 2.2. Click "Agreements (erm_agreements)" 2.3. Click "New field" 2.4. Enter the name "Agreements additional field" 2.5. Click "Save" 3. Enable the ERM module 3.1. Go to Administration > System preferences 3.2. Search for ERMModule 3.3. Set ERMModule to Enable 3.4. Click Save all E-resource management preferences 4. Add an agreement 4.1. Go to E-resource management > Agreements 4.2. Click "New agreement" --> Note that in the first section, both additional fields are displayed 4.3. Click "Add new period" --> The additional field for agreement periods is displayed -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 42833] New: Provider SSO icon size must auto
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42833 Bug ID: 42833 Summary: Provider SSO icon size must auto Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mhby87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Created attachment 200309 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200309&action=e… Big icon size not resize like staff login When I active SSO login in KOHA, I used provider Icon URL for login icon. When I click Login into account on OPAC right top, provider icon not resize like staf login or OPAC homepage login. Reffer attachment. Tq -- You are receiving this mail because: You are watching all bug changes.

1 21

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

22 Oct '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 12

[Bug 43370] New: Holdings table displays a user-selected column on the pages where it is empty
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 Bug ID: 43370 Summary: Holdings table displays a user-selected column on the pages where it is empty Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.derscheid(a)lmscloud.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- On the holdings table of the catalogue detail page, a column that has no value on the current page is hidden. update_columns_visibility() applies the user's column visibility choices after that pass, so a column the user turned on is displayed, empty, on the pages where it has no value. To reproduce: 1. Have a record with more than 20 items, e.g. biblionumber=4: kj build 42 items with biblionumber=4 2. Give a call number to the items of the first page only. UPDATE items SET itemcallnumber = NULL WHERE biblionumber = 4; UPDATE items SET itemcallnumber = CONCAT('CN-', itemnumber) WHERE biblionumber = 4 ORDER BY itemnumber LIMIT 20; 3. Go to /cgi-bin/koha/catalogue/detail.pl?biblionumber=4 4. In the column visibility menu, turn "Call number" off then on again. => The column is displayed on the first page, as expected. 5. Go to page 2. => The "Call number" column is displayed and empty for all rows. It should be hidden. 6. Go back to page 1. => The column is displayed again (correct). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 43838] New: Dayweek pushes dates by a whole week when it should move to the next open day
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43838 Bug ID: 43838 Summary: Dayweek pushes dates by a whole week when it should move to the next open day Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Blocks: 42334 Target Milestone: --- With useDaysMode (or the daysmode circulation rule) set to 'Dayweek', the "push to the same weekday" logic is applied in places where it shouldn't, moving dates a whole week instead of to the nearest open day. The cause is in Koha::Library::Calendar: next_open_days and prev_open_days call get_push_amt on every closed day they step over. Under Dayweek, get_push_amt returns 7 unless the weekday is a weekly closure. So any time those methods meet a closed day that is not a weekly closure, they jump a whole week, even when the caller just wants the next/previous open day. This dates back to bug 15260 (2019), which introduced Dayweek. Affected cases (library with no weekly closures, closed on Tue 2026-11-10 and Wed 2026-11-11, Dayweek): 1. ReturnBeforeExpiry: due date clamped to the patron expiry date on a closed day is moved back with prev_open_days( $datedue, 1 ). prev_open_days(Wed 11, 1) returns Tue 2026-11-03, expected Mon 2026-11-09. 2. TalkingTech_itiva_outbound.pl: waiting date on a closed day uses next_open_days( $waiting_date, 1 ) to compute days_since_waiting. next_open_days(Tue 10, 1) returns Wed 2026-11-18, expected Thu 2026-11-12. 3. Non-weekly loan periods: the syspref description says Dayweek pushes to "the next open day otherwise", but a 10-day loan from Sat 2026-10-31 (landing on Tue 10) is due Wed 2026-11-18, expected Thu 2026-11-12. Hourly loans ending on a closed day are affected in the same way, as addHours uses next_open_days too. Weekly loan periods should keep pushing to the next open matching weekday, as documented. Proposed fix: next_open_days and prev_open_days always step one day at a time, and only addDays applies the weekly push, for Dayweek and loan periods that are a whole number of weeks. This blocks bug 42334, which moves this logic to a new class. Fixing it here first keeps the fix small enough to be backported. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42334 [Bug 42334] Introduce Koha::Calendar::DateCalculator for date arithmetic -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 43877] New: Consolidate system preferences for checkout overrides
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43877 Bug ID: 43877 Summary: Consolidate system preferences for checkout overrides Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: testopia(a)bugs.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- We have five separate system preferences controlling whether or not staff are allowed to override a checkout restriction under different circumstances: AgeRestrictionOverride AllowFineOverride AllowHoldCheckoutOverride AllowNotForLoanOverride AllowTooManyOverride We should consolidate these into one multi-select system preference to improve both maintainability and user experience. -- You are receiving this mail because: You are watching all bug changes.

1 1