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

[Bug 43234] New: Move ILL request purging logic to Koha::ILL::Requests
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43234 Bug ID: 43234 Summary: Move ILL request purging logic to Koha::ILL::Requests Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 28740 Target Milestone: --- Follow-up from Bug 28740. Bug 28740 added ILL request purging to cleanup_database.pl using raw SQL in a PurgeIllRequests subroutine. This should be moved to a proper method on the Koha::ILL::Requests collection class. Proposed approach: - Add a filter method (e.g. filter_by_purgeable) that returns a filtered resultset - The script then calls ->count for dry-run or ->delete for actual purge - This follows the pattern used by other Koha::Objects subclasses Example usage in cleanup_database.pl: my $to_purge = Koha::ILL::Requests->filter_by_purgeable( { days => $days, statuses => \\@statuses } ); say sprintf('%d ILL requests would be removed', $to_purge->count) unless $confirm; $to_purge->delete if $confirm; Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28740 [Bug 28740] Delete old ILL requests with cleanup_database -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 41419] New: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41419 Bug ID: 41419 Summary: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org to reproduce 1. Go to Acquisitions → New vendor, enter a name, check Vendor is Active, and click Save. 2. Click the name of the vendor you just created in the table. 3. Click New → Basket, enter a basket name, and click Save. 4. Click Add to basket → From a new (empty) record. Enter a title, add an item, and click Save. 5. Click Close basket. 6. Click Receive shipments, enter a number in the Vendor invoice field, and click Next. 7. Click Receive for the created line. 8. Open the browser console. 9. In the modal, tick the Receive? checkbox and click Confirm. 10. Go to the previous page → The console shows the error: "undefined" is not valid JSON at JSON.parse (<anonymous>) was shown 11. Apply the patch 12. Go to Acquisitions → Search for the vandor created on step 2 13. Repeat step 3, 4, 5, 6, 7, 8, 9, 10 → There is no js error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43498] New: UNIMARC: authority search returns no results when the authority type is only in 942$a
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43498 Bug ID: 43498 Summary: UNIMARC: authority search returns no results when the authority type is only in 942$a Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org Depends on: 41795 Target Milestone: --- Bug 41795 added the completeness attribute (@attr 6=3) to the authtype clause in C4::AuthoritiesMarc::SearchAuthorities. Complete-field matching resolves against Zebra's phrase ('p') register. The UNIMARC authority index definitions build the authtype index from two places: - 152$b -> authtype:w authtype:p - 942$a -> authtype:w (word register only) On UNIMARC installations whose authority records carry the authority type in 942$a only (no 152 coded data field -- common in real-world UNIMARC sites), the authtype phrase register is empty, so every type-filtered authority search returns zero results. In particular, the authority finder launched from the bibliographic editor (e.g. on field 600) always passes an authtypecode, so cataloguers cannot search or link authorities at all. We hit this on three independent production UNIMARC installations (different servers, different Koha and Zebra builds) immediately after upgrading to releases containing Bug 41795 (26.05.00 / 25.11.05). On all of them nearly all authority records have the type in 942$a and no 152$b. Reproduced on current main with KTD (unimarc flavour, Zebra 2.2.8): 1) Create an authority whose type is in 942$a only; full authorities reindex. 2) Authority search with a type filter -> 0 results; the same search without a type filter finds the record. 3) yaz-client against the authority socket confirms the mechanism: @attr 1=authtype @attr 5=100 @attr 6=3 <value> -> 0 hits @attr 1=authtype @attr 5=100 <value> -> 1 hit The Bug 41795 follow-up ("add a phrase Zebra index for 'authtype'") fixed exactly this for MARC21 after the Jenkins failures, but the UNIMARC definitions were not updated (their 152$b block already had a :p index, which masked the 942$a case). The patch (to be attached) applies the same one-line change to the UNIMARC definitions: add authtype:p to the 942$a block in authority-koha-indexdefs.xml, with the regenerated authority-zebra-indexdefs.xsl. A full authorities reindex is required after applying -- worth flagging prominently if this gets backported (cf. Bug 41795 comment 19). Elasticsearch is not affected. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 [Bug 41795] UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 41795] New: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41795 Bug ID: 41795 Summary: UNIMARC: a Zebra search for Corporate Body Name authorities will also return Collective Titles Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org As per the Bug Summary, when you search for Corporate Body Name authorities (authtypecode 'CO') in the OPAC or in the Staff interface, the results will also include Collective Titles (authtypecode 'CO_UNI_TI'). The problem manifests in UNIMARC instances that use the default authority type codes and a Zebra search backend. AIUI, it has to do with 'Corporate Body Name' authorities using an authtypecode ('CO') that just so happens to be the prefix of another authtypecode ('CO_UNI_TI') used by 'Collective Title' authorities. Out of the box, MARC21 instances aren't affected by this. However, in the (unlikely?) scenario that you've decided to catalog authorities under different authtypes than the built-in ones and somehow managed to add new authority types that share the same prefix ('AUTH', 'AUTH_CORP', 'AUTH_PERS', etc.), then you will run into problems when searching as there will be no guarantee that filtering for the specific authority type 'AUTH' will return only the results you will be expecting. Elasticsearch is not affected -- it's a Zebra-only thing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 43497] New: LDAP auth by bind failing to fetch all LDAP attributes
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43497 Bug ID: 43497 Summary: LDAP auth by bind failing to fetch all LDAP attributes Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: accounts(a)nyabla.net QA Contact: martin.renvoize(a)openfifth.co.uk CC: dpavlin(a)rot13.org Target Milestone: --- The LDAP binds and successfully logs in pulling the cn, uid, and uidNumber fields, however, it is not able to access the mail field which is only accessible to the authenticated user. Looking at the flow of the authentication code, the LDAP server is bound to using the provided principal name and password, before searching for the uid using that binding, so it should be able to find the mail field, but it seems to be able to access everything but. I also tested with a perl script using the same Net::LDAP interface which was able to get all attributes without issue, and ldapsearch command line tool confirmed the same. LDAP section of koha-conf.xml: <ldapserver id="ldapserver"> <hostname>ldaps://pool.ldap.my.domain</hostname> <base>dc=my,dc=domain</base> <auth_by_bind>1</auth_by_bind> <replicate>1</replicate> <welcome>0</welcome> <update>1</update> <principal_name>uid=%s,ou=Accounts,ou=People,dc=my,dc=domain</principal_name> <mapping>  <surname is="cn"/> <userid is="uid"/> <email is="mail"/> <cardnumber is="uidNumber"/> <categorycode is="1">M</categorycode> <branchcode is="1">LIB</branchcode> </mapping> </ldapserver> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43495] New: Use the new opening hours facade in circulation due date calculations
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43495 Bug ID: 43495 Summary: Use the new opening hours facade in circulation due date calculations 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 43492, 43493 Target Milestone: --- C4::Circulation::CalcDateDue is currently the only functional consumer of library_hours: for hourly loan periods it looks up Koha::Library::Hours rows directly and snaps the due time to open_time/close_time depending on the ConsiderLibraryHoursInCirculation preference, with close to 140 lines of hand-rolled logic duplicated across the Days/Calendar branches, and no handling for slots that cross midnight or the multi-slot/typed hours introduced in Bug 43492. This bug replaces that direct table access with calls onto the Koha::Library::OpeningHours facade from Bug 43492 and Bug 43493 (for its Calendar-aware availability checks), removing Koha::Library::Hour(s) and the old library_hours table reference, and extending due date handling to correctly account for overnight and multi-day opening hours. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43492 [Bug 43492] Normalize library opening hours into a dedicated library_opening_hours table https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43493 [Bug 43493] Link Koha::Library opening hours with the library Calendar -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 43496] New: Rework the library opening hours administration interface
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43496 Bug ID: 43496 Summary: Rework the library opening hours administration interface Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 43492 Target Milestone: --- Bug 37456 reports being unable to type opening/closing times directly (the field behaved like a date picker limited to 12 hours/31 minutes) - this looks to already be resolved by Koha's migration to flatpickr in time-only mode, but the admin/branches.pl hours editor still assumes exactly one opening/closing pair per weekday, matching the old library_hours schema, so it cannot be used to enter the multiple time ranges per day requested in Bug 37616 and Bug 37708. This bug reworks the admin interface for the GENERAL opening hours type (introduced in Bug 43492) to support any number of time ranges per weekday, including slots that do not close again until a later day, while verifying the flatpickr time entry issue from Bug 37456 no longer reproduces. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43492 [Bug 43492] Normalize library opening hours into a dedicated library_opening_hours table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 13870] Add warnings about subscriptions and orders when deleting items
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #36 from Owen Leonard <oleonard(a)myacpl.org> --- > 6) When you edit or delete items (batch mode) you can see two new > columns about orders and subscriptions linked. You're referring to Cataloging -> Batch item modification and Cataloging -> Batch item deletion? I don't see any new columns. I'm testing with a subscription with items. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6796] Overnight checkouts taking into account opening and closing hours
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6796 Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43492 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43492 [Bug 43492] Normalize library opening hours into a dedicated library_opening_hours table -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0