https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43654
--- Comment #4 from Adolfo Rodríguez Taboada <[email protected]> --- 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. _______________________________________________ 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/
