https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654
--- Comment #7 from Andrew Fuerste-Henry <[email protected]> --- 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 <[email protected]> Co-Authored-By: Claude Sonnet 5 <[email protected]> Signed-off-by: David Nind <[email protected]> Signed-off-by: Andrew Fuerste Henry <[email protected]> -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
