https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 --- Comment #1 from Adolfo Rodríguez Taboada <adolfo.rodriguez@xercode.es> --- Created attachment 206909 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206909&action=edit Bug 43654: Item search: DataTables column filters ignored when 2+ conditions are combined. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #2 from David Nind <david@davidnind.com> --- I can't reproduce on current main the using the steps provided. This is what I did (using KTD): 1. Search > Item search 2. Enter initial search: - Home library is Centerville - Item type is Books ==> Results: 287 entries 3. Use column filters: - Title: perl ==> Results: down to 6 entries, no "Processing" 4. Clear filter, then: - Collection: select "Fiction" ==> Results: 4 entries -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 --- Comment #4 from Adolfo Rodríguez Taboada <adolfo.rodriguez@xercode.es> --- Thanks David — you were right that the original steps didn't reproduce the error. Turns out I picked the wrong example: Library/Item type are independent fixed fields (homebranch/itype), not part of the f/q/op/c condition builder this bug is about. The real reproduction needs 2+ rows in the "Search for" box (barcode/title/author/itemcallnumber/etc., via "+ New field"). I reproduced it locally with temporary debug logging and found the actual corruption is worse than "filter ignored": with 2 conditions, f/q/op/c end up with mismatched array lengths after a column filter is applied, losing the original search conditions entirely. That same debugging also caught a bug in my own v1 patch: c (the AND/OR conjunction) doesn't always follow the same bracket convention as f/q/op — its <select> is disabled on the first row, so with exactly 2 conditions only one c value is sent, unbracketed, even though f/q/op are bracketed. v1 used a single flag for all four params, which broke this common case. v2 (attached, obsoletes 206909) checks the bracket convention independently per field, matching what Bug 36930's filter constructor already does. Updated test plan is in the patch description. Sorry for the churn, and thanks for catching it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #207841|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes item search in release notes| |the staff interface (Search | |> Item search) so that the | |filters in the search | |results now work as | |expected. | | | |Before the patch: when | |using multiple search | |criteria in the section | |where you can enter | |specific values for fields | |(such as Barcode, Title, | |and so on), using the | |filters in the search | |results table did not do | |anything. For example | |(using sample data in | |koha-testing-docker): | |- Barcode is 3999% | |- AND Title is %perl% | | ==> Results: 18 | |- In the filter for the | |Title column, enter | |template | | ==> Results: no change to | |results | | | |After the patch: filters in | |the table now work as | |expected. --- Comment #6 from David Nind <david@davidnind.com> --- I amended the commit message for step 1 of the test plan (Go to Search > Item search - instead of Cataloging > Item search). Updated testing notes (using KTD): 1. Search > Item search 2. Enter initial search: - Barcode is 3999% - AND Title is %perl% ==> Results: 18 3. Use column filters (clear between adding filters, or add as additional filters): 3.1 In the filter for the Title column, enter template ==> Result: no change to results 3.2 In the filter for the Publication date enter 2000 ==> Result: no change to results 3.3 In the dropdown filter for the Collection column change to Fiction ==> Result: no change to results 4. After the patch is applied, the filters work as expected. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 --- Comment #7 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 207978 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207978&action=edit Bug 43654: Item search: DataTables column filters ignored when 2+ conditions are combined Bug 36930 fixed item search returning wrong results when 2+ added conditions were combined, by making the filter constructor check, independently for each of 'f'/'q'/'op'/'c', whether that parameter arrived as the bracketed array name (e.g. 'f[]', sent by JS when a field repeats) or the plain name (single value), and read/write consistently. However, the JSON-preprocessing block that merges DataTables column filters (free-text search box and dropdowns for library, item type, etc. in the results table) still unconditionally read from multi_param('f')/('q')/('op')/('c') without brackets. With 2+ conditions in the "Search for" row builder, the JS sends those as bracketed arrays, so multi_param('f') etc. returned empty: the original conditions were lost, and the column filter value was pushed onto an otherwise-empty array and written back to the plain param, which the filter constructor further down (fixed by Bug 36930) never reads, since it looks at the bracketed name. The column filters were silently ignored and the results table got stuck on "Processing". Note that 'c' (the AND/OR conjunction) does not necessarily follow the same bracket convention as 'f'/'q'/'op': its <select> is disabled on the first condition row (no conjunction needed before the first condition), and disabled form fields are never submitted by the browser. With exactly 2 conditions, only one 'c' value is sent (not repeated, so plain 'c'), even though 'f'/'q'/'op' are sent bracketed (repeated twice). An earlier version of this patch detected the bracket convention once from 'f[]' and applied it to all four parameters, which broke this common 2-condition case: it read multi_param('c[]') (empty) instead of multi_param('c') (the real value), losing the conjunction and producing mismatched array lengths for f/q/op/c. Fixed by checking the bracket convention independently for each parameter, the same way the Bug 36930 filter constructor already does. Steps to follow: 1. Go to Search > Item search. 2. In the "Search for" section (barcode/title/author/etc. - NOT the Library/Item type dropdowns further up, which are independent fixed fields and don't exercise this code at all), enter a condition in the first row (e.g. Title / is / a common word), then click "+ New field" to add a second row with another condition (e.g. Author / is / a letter). 3. Run the search. 4. Try to filter further using one of the result table's column filters (a free-text column filter, or a dropdown column filter such as Library or Collection). Confirm the filter has no effect and/or the table stays on "Processing" - bug confirmed. 5. Apply this patch and restart Plack if running under it. 6. Repeat step 4. Confirm the column filter now applies correctly and the original 2 conditions are still honored. 7. Verify a search with only 1 condition in "Search for" still works as before (column filters already worked in that case - no regression). Signed-off-by: Adolfo Rodríguez <adolfo.rodriguez@xercode.es> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.11.00 released in| | --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Pushed to main for 26.11 with consent from Pedro whilst he's on annual leave -- You are receiving this mail because: You are watching all bug changes.