Saw this on today's maint branch. Open a split register for an account. Select Edit->Find Choose "Date Posted" and configure a date filter that should only show part of the transactions in the register. Hit Find => All transactions are displayed after all Expected: only the transactions matching the filter are displayed.
Did some additional bisecting. Apparently the bug is introduced with this commit: https://github.com/Gnucash/gnucash/commit/e281b50b2963dfe2243bff "Add new filter option to register" I'm cc'ing Bob. I think it goes wrong with the removal of the call to xaccQueryGetDateMatchTT(query, &start_time, &end_time); What we missed is that search results are also displayed in a GL type ledger, but with a query pre-set. The changes in the above commit ignore this.
OK I can fix this by doing this but it only works for the initial load... /* Update Query with Filter Status and Dates */ if (reg->type != SEARCH_LEDGER) { gnc_ppr_update_status_query (page); gnc_ppr_update_date_query (page); } If you use the 'Filter By' dialogue on the search results, it would resort back to the full list. Using xaccQueryGetDateMatchTT function does not work as it is restricted to QOF_COMPARE_LTE and QOF_COMPARE_GTE values but one would also have a problem when doing a Edit->Find and then Reconcile as those values would need to match that on the filter also. So what I am thinking, with the above change to also disable the 'Filter By' option for the search results, if you want to refine the search you would just do Edit->Find and the 'Refine Current Search' is already selected. What do you think, not sure how difficult it would be to do.
Disabling "Filter By' on search results is one option. What I dislike about this is that it papers over a logic issue by making the code path unavailable from the GUI. It doesn't solve the logic issue itself. While I haven't investigated in detail I think what happens here is a clash of query parameters. That is, "Find" opens a register with a qofquery set. "Filter by" code doesn't take this sufficiently into account and messes up this query to create its own. So one way out of this is making the "Filter by" code aware of the pre-existing query and AND it's own query parameters to this existing query. That would allow the user to use "Filter by" on top of "Find". Filter by is sometimes easier to set up than a formal Find dialog. So: - when creating the search ledger, save the initial query if there is one. - when Filter by kicks in, add the filter parameters to a copy of this initial query I don't know if "Find" will keep these additional Filter By parameters if you start a "refine current search". That probably becomes too complicated. I'd suggest priming the search dialog with the initial query instead in that case.
OK, will investigate further, I have noticed that the gnc_ppr_update_date_query and gnc_ppr_update_status_query use qof_query_purge_terms so resetting the query on each call, will look at changing that for a search register.
Bob's PR 407 fixes this and is merged for GnuCash 3.3.
