https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43241 Bug ID: 43241 Summary: REST API: q= parameter bypasses datetime conversion for values nested in DBIC operators Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: tomascohen@gmail.com QA Contact: testopia@bugs.koha-community.org CC: tomascohen@gmail.com Target Milestone: --- When datetime filter values are passed inside DBIC operators (-and, -or) in the q= parameter, _recursive_fixup is never called on them. This means RFC3339 timestamps (e.g. 2026-08-05T00:00:00Z) reach MySQL unconverted. On tables with many rows (e.g. action_logs), MySQL cannot use the timestamp index when comparing against ISO 8601 format with the T separator, causing full table scans and very slow responses. The root cause is architectural: 1. _parse_dbic_query (in Koha::REST::Plugin::Query) maps field names but does not convert values 2. attributes_from_api (which calls _recursive_fixup for the conversion) is called on the merged result, but only iterates top-level keys 3. When the top-level key is -and or -or, the nested column values are passed through without fixup This affects any kohaTable-based page that combines default_filters with a global search term, since the DataTables layer wraps the combined query in -and. The fix: - Move attributes_from_api to process named query params before merging with q params - Teach _parse_dbic_query to call _recursive_fixup when it encounters a key that maps to a known column This ensures RFC3339 values are converted to MySQL-native format regardless of query nesting depth. Related: Bug 43208 (reported as a viewlog performance issue, same root cause) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.